Static inline DRM functions calling into GPL-only code

Nikhil Mahale nmahale at
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 
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 

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?

Nikhil Mahale

More information about the dri-devel mailing list