All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikhil Mahale <nmahale@nvidia.com>
To: dri-devel@lists.freedesktop.org
Subject: Static inline DRM functions calling into GPL-only code
Date: Tue, 11 Apr 2017 09:44:35 +0530	[thread overview]
Message-ID: <870d9497-2b8f-92bb-c763-1198208d3931@nvidia.com> (raw)

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2017-04-11  4:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11  4:14 Nikhil Mahale [this message]
2017-04-11  5:52 ` Static inline DRM functions calling into GPL-only code Daniel Vetter
2017-04-11  6:20   ` Daniel Vetter
2017-04-11 15:15     ` James Jones
2017-04-11 16:09       ` Harry Wentland
2017-04-11 16:37         ` James Jones
2017-04-11 17:33           ` Harry Wentland
2017-04-11  7:24 ` nvidia vgaarb bug (was: Re: Static inline DRM functions calling into GPL-only code) Lukas Wunner
2017-04-12 22:46   ` Andy Ritger
2017-12-06 11:24     ` Lukas Wunner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=870d9497-2b8f-92bb-c763-1198208d3931@nvidia.com \
    --to=nmahale@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.