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

[Andy Ritger]

On Tue, Apr 18, 2017 at 10:26:39PM +0200, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 7:55 PM, Andy Ritger <aritger at nvidia.com> wrote:
> > 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.
> 
> So I'm a layman and all that, but I don't get why this is relevant at
> all. Speaking for myself, not my employer, not legal advice, yadayada,
> but I see two options:
> 
> - the blob has become at least partially a derived work of the linux
> kernel work. You're fucked, whether you use gpl only symbols or not,
> because if there ever was some meaning to labelling stuff gpl-only it
> has long evaporated imo and become a pure political thing.
> 
> - it is still a clearly independent work. There's no problem, because
> only the nvidia-drm impendence mismatch layer is a derived work (no on
> argues that I guess), and that along could easily ship as a part of
> the kernel with the overall GPL license. Of course upstream wont do
> that because it'd be pointless, but I don't see a problem.
> 
> So either labelling it as dual MIT/GPL isn't really a problem, or
> labelling it as MIT-only isn't going to save your (legally speaking at
> least).
> 
> Doing simple wrappers around gpl-only symbols otoh like you do here
> isn't any different from shipping it as part of nvidia-drm, at least I
> don't see how this factually changes anything.

>From my perspective, the distinction is:

* How drm functions are implemented is an implementation detail of drm.
  The implementations of these functions use kref/refcount_t today because
  they are well-proven primitives in the kernel.  But, they could just
  as easily have an entirely different implementation, and drm drivers
  don't need to care.

* In contrast, if nvidia-drm directly accesses kref/refcount_t, we were
  worried it would be perceived by some as an attempt to side-step the
  intent of refcount_t being EXPORT_SYMBOL_GPL in the first place.
  My goal was just for nvidia-drm to plug into the drm subsystem, not to
  use any facilities that were deemed low-level implementation details
  of the kernel.

Thanks,
- Andy