Bug#809324: Same issue here

[Luca Boccassi]

On 14 January 2016 at 22:38, Andreas Beckmann <anbe at debian.org> wrote:
> On 2016-01-12 23:43, Luca Boccassi wrote:
>> Andreas, what do you think we should do? I've committed a patch to SVN
>> (tested that the module builds on x86 and x86_64 on 3.16, 4.2, 4.3 and
>> 4.4, but I don't have hardware to do anything beyond that
>> unfortunately). Hopefully the next upstream patch release will fix it
>> and we can revert it.
>
> That looks OK to me. I cannot test it either :-)
>
> I just saw
>
> https://anonscm.debian.org/viewvc/pkg-fglrx/fglrx-driver/trunk/debian/patches/12-4.3.0-build.patch?revision=1549&view=markup
>
> which seems to handle this issue for fglrx.
>
> (but fglrx causes a kernel null pointer dereference in 4.3, not sure
> whether it is related to this stuff)
>
> Comments?

The new kernel API [1] mandates that the delete call should pass in as
the input parameter the value returned by the add call. This is
different from the older API, which required no state, and the kernel
module shim used by the binary blob does not support such a behaviour
as far as I can see, as it just returns an error code. See
kernel/os-mtrr.c, signatures:

RM_STATUS NV_API_CALL os_set_mem_range( NvU64 start, NvU64 size, NvU32 mode)

RM_STATUS NV_API_CALL os_unset_mem_range(NvU64 start, NvU64 size)

Given these are called from the binary blob, we can't change that API:

$ strings nv-kernel.o | grep set_mem_range
os_unset_mem_range
os_set_mem_range

Kind regards,
Luca Boccassi

[1] http://lxr.free-electrons.com/source/arch/x86/kernel/cpu/mtrr/main.c#L531