Static inline DRM functions calling into GPL-only code

[Daniel Vetter]

On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale <nmahale at nvidia.com> wrote:
> My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers
> team.
>
> I have been working on adding DRM KMS support to our driver. The NVIDIA
> GPU driver package (364.12 and higher) provides a kernel module,
> nvidia-drm.ko, which is licensed as "MIT". This module registers a DRM
> driver with the DRM subsystem of the Linux kernel and advertises KMS
> capability on Linux kernel v4.1 or higher, with CONFIG_DRM and
> CONFIG_DRM_KMS_HELPER enabled.
>
> We have been able to maintain compatibility between nvidia-drm.ko and
> Linux kernels from v2.6.9 to v4.10. Unfortunately
> with release candidates of v4.11:
>
> * Commit 10383aea2f445bce9b2a2b308def08134b438c8e changed the kernel's
> kref implementation to use refcount_inc and refcount_dec_and_test.
> * Commit 29dee3c03abce04cd527878ef5f9e5f91b7b83f4 made refcount_inc and
> refcount_dec_and_test EXPORT_SYMBOL_GPL.
>
> DRM drivers call refcount_inc through static inline function callchains
> such as:
>
>     drm_crtc_commit_put() => kref_put() => refcount_dec_and_test()
>     drm_crtc_commit_get() => kref_get() => refcount_inc()
>
>     drm_atomic_state_put() => kref_put() => refcount_dec_and_test()
>     drm_atomic_state_get() => kref_get() => refcount_inc()
>
>     drm_gem_object_reference() => kref_get => refcount_inc()
>
> This causes nvidia-drm.ko to inadvertently pick up references to
> EXPORT_SYMBOL_GPL symbols.
>
> There is not interest in relaxing the export of refcount_inc, and
> changing the license of nvidia-drm.ko isn't viable right now.
>
> So, the remaining options we see are:
>
> * Make these static inline DRM functions EXPORT_SYMBOL instead of
> inline.
>
> * Make these static inline DRM functions not use kref.
>
> * Make nvidia-drm.ko not use these static inline DRM functions.
>
> None of those seem good, though the first might be least bad.  Do any of
> those seem reasonable?

* Open-source the nvidia kernel driver? tbh I'm not sure how much you
can still make the case that your driver is fully an independent thing
if you're adopting stuff like atomic modesetting. Might be better to
make all the glue/remapping code from linux atomic to the shared
cross-os code at least open ... And atomic is pretty much guaranteed
to change all the time anyway, we're definitely not going to make a
stable kabi for you folks, so you might want to do that for practical
reasons anyway.

Just my 2cents, personal opinion, not reflecting intel's, not legal
advice, yadayada and all that :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch