Static inline DRM functions calling into GPL-only code

[Nikhil Mahale]

Hi,

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?

-- 
Thanks,
Nikhil Mahale