From: John Hubbard <[email protected]>
Hi,
Say, I'm 99% sure that this was just an oversight, so
I'm sticking my neck out here and floating a patch to
Put Things Back. I'm hoping that there is not some
firm reason to GPL-protect the basic kref_get and
kref_put routines, because when designing some
recent new (open-source, yay!) device drivers, we relied
on this being available, even for MIT-licensed code.
John Hubbard (1):
refcount: restore kref_get and kref_put to non-GPL status
lib/refcount.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.12.0
From: John Hubbard <[email protected]>
Originally, kref_get and kref_put were available as
standard routines that even non-GPL device drivers
could use. However, as an unintended side effect of
the recent kref_*() upgrade[1], these calls are now
effectively GPL, because they get routed to the
new refcount_inc() and refcount_dec_and_test()
routines.
Make just those routines non-GPL, in order to restore
the original behavior--and to avoid forcing simple
users of krefs to re-implement atomic refcounting.
[1] commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
Signed-off-by: John Hubbard <[email protected]>
---
lib/refcount.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/refcount.c b/lib/refcount.c
index aa09ad3c30b0..6421a4930484 100644
--- a/lib/refcount.c
+++ b/lib/refcount.c
@@ -113,7 +113,7 @@ void refcount_inc(refcount_t *r)
{
WARN_ONCE(!refcount_inc_not_zero(r), "refcount_t: increment on 0; use-after-free.\n");
}
-EXPORT_SYMBOL_GPL(refcount_inc);
+EXPORT_SYMBOL(refcount_inc);
bool refcount_sub_and_test(unsigned int i, refcount_t *r)
{
@@ -152,7 +152,7 @@ bool refcount_dec_and_test(refcount_t *r)
{
return refcount_sub_and_test(1, r);
}
-EXPORT_SYMBOL_GPL(refcount_dec_and_test);
+EXPORT_SYMBOL(refcount_dec_and_test);
/*
* Similar to atomic_dec(), it will WARN on underflow and fail to decrement
--
2.12.0
On 03/08/2017 01:50 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 08, 2017 at 01:25:49AM -0800, [email protected] wrote:
>> From: John Hubbard <[email protected]>
>>
>> Originally, kref_get and kref_put were available as
>> standard routines that even non-GPL device drivers
>> could use.
>
> As I stated in my response to the 0/1 of this patch, this sentence is
> not true, sorry, the inlined functions were GPL-v2-only.
OK, got it. I overlooked that point.
thanks
John Hubbard
NVIDIA
>
> thanks,
>
> greg k-h
>
On Wed, Mar 08, 2017 at 01:25:48AM -0800, [email protected] wrote:
> From: John Hubbard <[email protected]>
>
> Hi,
>
> Say, I'm 99% sure that this was just an oversight, so
> I'm sticking my neck out here and floating a patch to
> Put Things Back. I'm hoping that there is not some
> firm reason to GPL-protect the basic kref_get and
> kref_put routines, because when designing some
> recent new (open-source, yay!) device drivers, we relied
> on this being available, even for MIT-licensed code.
MIT-licensed code should be just fine with GPL symbols, just use the
correct MODULE_LICENSE() setting and all is good.
As all of the previous kref functions were in a GPL-only header file,
and included directly that way, they were already GPL-only symbols, so
there really was no change here except now the linker checks them. If
you have questions about using inline GPL-only functions from a .h file,
in a non-GPL codebase, please consult your corporate lawyer to get
clarification.
thanks,
greg k-h
On Wed, Mar 08, 2017 at 01:25:49AM -0800, [email protected] wrote:
> From: John Hubbard <[email protected]>
>
> Originally, kref_get and kref_put were available as
> standard routines that even non-GPL device drivers
> could use.
As I stated in my response to the 0/1 of this patch, this sentence is
not true, sorry, the inlined functions were GPL-v2-only.
thanks,
greg k-h
On Wed, Mar 08, 2017 at 01:59:33AM -0800, John Hubbard wrote:
>
>
> On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
> > On Wed, Mar 08, 2017 at 01:25:48AM -0800, [email protected] wrote:
> > > From: John Hubbard <[email protected]>
> > >
> > > Hi,
> > >
> > > Say, I'm 99% sure that this was just an oversight, so
> > > I'm sticking my neck out here and floating a patch to
> > > Put Things Back. I'm hoping that there is not some
> > > firm reason to GPL-protect the basic kref_get and
> > > kref_put routines, because when designing some
> > > recent new (open-source, yay!) device drivers, we relied
> > > on this being available, even for MIT-licensed code.
> >
> > MIT-licensed code should be just fine with GPL symbols, just use the
> > correct MODULE_LICENSE() setting and all is good.
>
> Actually, we're still using this license string:
>
> MODULE_LICENSE("MIT");
>
> which I understand does *not* grant access to GPL symbols. So I guess we'd
> have to switch over to "MIT/GPL", if I understand correctly, in order to be
> all correct here.
You need to write this as:
MODULE_LICENSE("Dual MIT/GPL");
for the linker to handle this properly as that is the string it is
looking for.
thanks,
greg k-h
On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 08, 2017 at 01:25:48AM -0800, [email protected] wrote:
>> From: John Hubbard <[email protected]>
>>
>> Hi,
>>
>> Say, I'm 99% sure that this was just an oversight, so
>> I'm sticking my neck out here and floating a patch to
>> Put Things Back. I'm hoping that there is not some
>> firm reason to GPL-protect the basic kref_get and
>> kref_put routines, because when designing some
>> recent new (open-source, yay!) device drivers, we relied
>> on this being available, even for MIT-licensed code.
>
> MIT-licensed code should be just fine with GPL symbols, just use the
> correct MODULE_LICENSE() setting and all is good.
Actually, we're still using this license string:
MODULE_LICENSE("MIT");
which I understand does *not* grant access to GPL symbols. So I guess we'd have to
switch over to "MIT/GPL", if I understand correctly, in order to be all correct here.
>
> As all of the previous kref functions were in a GPL-only header file,
> and included directly that way, they were already GPL-only symbols, so
> there really was no change here except now the linker checks them. If
> you have questions about using inline GPL-only functions from a .h file,
> in a non-GPL codebase, please consult your corporate lawyer to get
> clarification.
As much as I do enjoy chatting with those guys, I think I'll pass this time. :)
thanks,
John Hubbard
NVIDIA
>
> thanks,
>
> greg k-h
>
On 03/08/2017 02:12 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 08, 2017 at 01:59:33AM -0800, John Hubbard wrote:
>>
>>
>> On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
>>> On Wed, Mar 08, 2017 at 01:25:48AM -0800, [email protected] wrote:
>>>> From: John Hubbard <[email protected]>
>>>>
>>>> Hi,
>>>>
>>>> Say, I'm 99% sure that this was just an oversight, so
>>>> I'm sticking my neck out here and floating a patch to
>>>> Put Things Back. I'm hoping that there is not some
>>>> firm reason to GPL-protect the basic kref_get and
>>>> kref_put routines, because when designing some
>>>> recent new (open-source, yay!) device drivers, we relied
>>>> on this being available, even for MIT-licensed code.
>>>
>>> MIT-licensed code should be just fine with GPL symbols, just use the
>>> correct MODULE_LICENSE() setting and all is good.
>>
>> Actually, we're still using this license string:
>>
>> MODULE_LICENSE("MIT");
>>
>> which I understand does *not* grant access to GPL symbols. So I guess we'd
>> have to switch over to "MIT/GPL", if I understand correctly, in order to be
>> all correct here.
>
> You need to write this as:
> MODULE_LICENSE("Dual MIT/GPL");
> for the linker to handle this properly as that is the string it is
> looking for.
Yes, understood. I thought from your previous response that maybe "MIT" alone was
*intended* to provide access, but this makes sense and matches what I'd thought
earlier. And of course, your other point (about the header itself being licensed)
overrides this, but it's nice to get clarification on this detail, as long as I'm
stuck--for now--on "MIT".
Appreciate your time and quick responses on this, I know it's probably tiresome to
answer these sorts of questions.
thanks again,
john h
>
> thanks,
>
> greg k-h
>
Hi John,
all Linux kernel code is licenced under the GPLv2.0, and maybe only
be used by derived works if that work is available under a
GPL-compatible license. the _GPL export are just a very strong hint
that it's almost impossible not to be derived work - using non-trivial
inline functions should be a just as strong hint so this is not going
to change anything.