Static inline DRM functions calling into GPL-only code
nmahale at nvidia.com
Tue Apr 11 04:14:35 UTC 2017
My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers
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
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
DRM drivers call refcount_inc through static inline function callchains
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
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
* 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?
More information about the dri-devel