[PATCH 0/2] Do not call kref utility functions from static inline code

[Andy Ritger]

I don't expect these two patches to be terribly popular, but let's see.

Nikhil Mahale described the problem here:

    https://lists.freedesktop.org/archives/dri-devel/2017-April/138731.html

In short:

    Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
    updated the kref implementation to use refcount_t.  Commit 29dee3c03abc
    ("locking/refcounts: Out-of-line everything") changed the refcount_t
    utility functions from static inline to EXPORT_SYMBOL_GPL functions.

    Through a chain of drm -> kref -> refcount static inline utility
    functions, drm drivers can inadvertently pick up a reference to the
    EXPORT_SYMBOL_GPL refcount_t functions.

To be clear: in the case of NVIDIA's dGPU driver, all the code that
interfaces with drm is in the MIT-licensed nvidia-drm.ko kernel module
(i.e., what Daniel Vetter suggested in response to Nikhil).  Churn in
the drm interfaces exposed to drm drivers is fine from NVIDIA's point
of view, and the burden is NVIDIA's to maintain an out-of-tree drm driver.

Elsewhere in that thread, Lukas Wunner asked why nvidia-drm.ko is licensed
MIT rather than MIT+GPL:

    https://lists.freedesktop.org/archives/dri-devel/2017-April/139033.html

I explained:

    We intentionally chose MODULE_LICENSE("MIT") for nvidia-drm.ko, rather
    than MODULE_LICENSE("Dual MIT/GPL"), to avoid any ambiguity:

    * nvidia-drm.ko depends on nvidia.ko, which is MODULE_LICENSE("NVIDIA").

    * nvidia-drm.ko is the portion of the NVIDIA dGPU driver that interfaces
      with DRM in the kernel.  We wouldn't want nvidia-drm.ko to
      inadvertently function as, or even be perceived as, a path for
      nvidia.ko to indirectly get access to EXPORT_SYMBOL_GPL symbols.

If it is reasonable for there to be MIT drm drivers, then hopefully it
is reasonable for the interface exported by drm to drm drivers to not
require EXPORT_SYMBOL_GPL.

I admit that losing static inline on the functions in these patches is
unfortunate.  Sorry.  At least, I don't expect any of these functions
would be used in particularly perf-critical paths.

I should also note that I attempted to remove all kref helper function
calls from static inline drm functions.  This is more than strictly
necessary for NVIDIA's needs.  But, it seemed good to be consistent.


Andy Ritger (2):
  drm: Do not call kref utility functions from static inline code
  dma-fence: Do not call kref utility functions from static inline code

 drivers/dma-buf/dma-fence.c       | 41 +++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_atomic.c      | 51 +++++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_framebuffer.c | 12 +++++++++
 drivers/gpu/drm/drm_gem.c         | 35 +++++++++++++++++++++++++++
 include/drm/drm_atomic.h          | 50 +++-----------------------------------
 include/drm/drm_framebuffer.h     | 12 +--------
 include/drm/drm_gem.h             | 36 ++-------------------------
 include/linux/dma-fence.h         | 40 +++---------------------------
 8 files changed, 149 insertions(+), 128 deletions(-)

-- 
2.1.0