To whoever may know,
Upon loading our driver module I get the following message:
kernel: [ 344.805106] Disabling lock debugging due to kernel taint
What exactly are the criteria for tainting? Our driver locking strategy
is something we want to refactor and having lock debugging during that
transition may be a life safer.
Gr. AvS
On 12/16/2011 02:53 PM, Larry Finger wrote:
>
> I also found that loading brcmsmac did not trigger the license taint. I think
> you are OK with the dual license.
Ok. I get it upon loading the brcmutil module. Actually, my usage
scenario is:
1) build the driver modules in kernel tree on my development machine.
2) rsync the brcm80211 folder to my test machine.
3) insert the driver modules on my test machine.
> Larry
>
Gr. AvS
On Fri, 2011-12-16 at 07:53 -0600, Larry Finger wrote:
> On 12/16/2011 06:30 AM, Johannes Berg wrote:
> > On Fri, 2011-12-16 at 10:27 +0100, Arend van Spriel wrote:
> >> To whoever may know,
> >>
> >> Upon loading our driver module I get the following message:
> >>
> >> kernel: [ 344.805106] Disabling lock debugging due to kernel taint
> >>
> >> What exactly are the criteria for tainting? Our driver locking strategy
> >> is something we want to refactor and having lock debugging during that
> >> transition may be a life safer.
> >
> > cat /proc/sys/kernel/tainted
>
> Please note that Documentation/sysctl/kernel.txt is missing the explanation for
> two bits in the value printed:
>
> 2048 - The system is working around a severe firmware bug.
> 4096 - An out-of-tree module has been loaded.
>
> On my system, bit 4096 is set due to loading the VirtualBox module, which
> disables lock debugging lock debugging. I suspect that loading VMware would
> cause the same condition.
Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
modules OOT because the turnaround is faster/easier (for not so
experienced developers). Worst case we can patch it out of the base
kernel I guess...
johannes
On 12/16/2011 08:20 AM, Johannes Berg wrote:
> On Fri, 2011-12-16 at 08:13 -0600, Larry Finger wrote:
>
>>> Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
>>> modules OOT because the turnaround is faster/easier (for not so
>>> experienced developers). Worst case we can patch it out of the base
>>> kernel I guess...
>>
>> Me too. Now I understand John's patch entitled "[RFC] modpost: add option to
>> allow external modules to avoid taint". I doubt that it will be allowed
>> upstream, but I think that I will add it as a local commit.
>
> I was thinking more along the lines of this:
>
> --- wireless-testing.orig/kernel/panic.c 2011-12-10 17:32:26.000000000 +0100
> +++ wireless-testing/kernel/panic.c 2011-12-16 15:19:49.000000000 +0100
> @@ -240,8 +240,16 @@ void add_taint(unsigned flag)
> * Also we want to keep up lockdep for staging development and
> * post-warning case.
> */
> - if (flag != TAINT_CRAP&& flag != TAINT_WARN&& __debug_locks_add_taint
off())
> - printk(KERN_WARNING "Disabling lock debugging due to kernel taint\n");
> + switch (flag) {
> + case TAINT_CRAP:
> + case TAINT_WARN:
> + case TAINT_OOT_MODULE:
> + break;
> + default:
> + if (__debug_locks_off())
> + printk(KERN_WARNING
> + "Disabling lock debugging due to kernel taint\n");
> + }
>
> set_bit(flag,&tainted_mask);
> }
Yes. I like this patch a lot. Unfortunately, VirtualBox was a part of the
decision to add the OOT taint. At least for that reason, this patch would not be
accepted upstream. It is too bad that the Oracle people fought so hard to keep
their module from setting TAINT_CRAP the way that GregKH wanted. That would have
had fewer side effects for me.
Larry
On Fri, 2011-12-16 at 08:13 -0600, Larry Finger wrote:
> > Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
> > modules OOT because the turnaround is faster/easier (for not so
> > experienced developers). Worst case we can patch it out of the base
> > kernel I guess...
>
> Me too. Now I understand John's patch entitled "[RFC] modpost: add option to
> allow external modules to avoid taint". I doubt that it will be allowed
> upstream, but I think that I will add it as a local commit.
I was thinking more along the lines of this:
--- wireless-testing.orig/kernel/panic.c 2011-12-10 17:32:26.000000000 +0100
+++ wireless-testing/kernel/panic.c 2011-12-16 15:19:49.000000000 +0100
@@ -240,8 +240,16 @@ void add_taint(unsigned flag)
* Also we want to keep up lockdep for staging development and
* post-warning case.
*/
- if (flag != TAINT_CRAP && flag != TAINT_WARN && __debug_locks_off())
- printk(KERN_WARNING "Disabling lock debugging due to kernel taint\n");
+ switch (flag) {
+ case TAINT_CRAP:
+ case TAINT_WARN:
+ case TAINT_OOT_MODULE:
+ break;
+ default:
+ if (__debug_locks_off())
+ printk(KERN_WARNING
+ "Disabling lock debugging due to kernel taint\n");
+ }
set_bit(flag, &tainted_mask);
}
On 12/16/2011 08:48 AM, Nick Bowler wrote:
> On 2011-12-16 14:58 +0100, Johannes Berg wrote:
>> Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
>> modules OOT because the turnaround is faster/easier (for not so
>> experienced developers). Worst case we can patch it out of the base
>> kernel I guess...
>
> Indeed, but the good news is that we should finally be able to put this
> issue behind us soon(ish).
>
> https://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=9ec84acee1e221d99dc33237bff5e82839d10cc0
Is that patch queued for 3.3?
Larry
On 12/16/2011 06:30 AM, Johannes Berg wrote:
> On Fri, 2011-12-16 at 10:27 +0100, Arend van Spriel wrote:
>> To whoever may know,
>>
>> Upon loading our driver module I get the following message:
>>
>> kernel: [ 344.805106] Disabling lock debugging due to kernel taint
>>
>> What exactly are the criteria for tainting? Our driver locking strategy
>> is something we want to refactor and having lock debugging during that
>> transition may be a life safer.
>
> cat /proc/sys/kernel/tainted
Please note that Documentation/sysctl/kernel.txt is missing the explanation for
two bits in the value printed:
2048 - The system is working around a severe firmware bug.
4096 - An out-of-tree module has been loaded.
On my system, bit 4096 is set due to loading the VirtualBox module, which
disables lock debugging lock debugging. I suspect that loading VMware would
cause the same condition.
I also found that loading brcmsmac did not trigger the license taint. I think
you are OK with the dual license.
Larry
On 2011-12-16 14:58 +0100, Johannes Berg wrote:
> Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
> modules OOT because the turnaround is faster/easier (for not so
> experienced developers). Worst case we can patch it out of the base
> kernel I guess...
Indeed, but the good news is that we should finally be able to put this
issue behind us soon(ish).
https://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=9ec84acee1e221d99dc33237bff5e82839d10cc0
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Hello,
On Fri, Dec 16, 2011 at 11:27 AM, Arend van Spriel <[email protected]> wrote:
> To whoever may know,
>
> Upon loading our driver module I get the following message:
>
> kernel: [ ?344.805106] Disabling lock debugging due to kernel taint
>
> What exactly are the criteria for tainting? Our driver locking strategy
> is something we want to refactor and having lock debugging during that
> transition may be a life safer.
Is your driver GPL licensed?
thanks,
Daniel.
On 12/16/2011 07:58 AM, Johannes Berg wrote:
> On Fri, 2011-12-16 at 07:53 -0600, Larry Finger wrote:
>> On 12/16/2011 06:30 AM, Johannes Berg wrote:
>>> On Fri, 2011-12-16 at 10:27 +0100, Arend van Spriel wrote:
>>>> To whoever may know,
>>>>
>>>> Upon loading our driver module I get the following message:
>>>>
>>>> kernel: [ 344.805106] Disabling lock debugging due to kernel taint
>>>>
>>>> What exactly are the criteria for tainting? Our driver locking strategy
>>>> is something we want to refactor and having lock debugging during that
>>>> transition may be a life safer.
>>>
>>> cat /proc/sys/kernel/tainted
>>
>> Please note that Documentation/sysctl/kernel.txt is missing the explanation for
>> two bits in the value printed:
>>
>> 2048 - The system is working around a severe firmware bug.
>> 4096 - An out-of-tree module has been loaded.
>>
>> On my system, bit 4096 is set due to loading the VirtualBox module, which
>> disables lock debugging lock debugging. I suspect that loading VMware would
>> cause the same condition.
>
> Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
> modules OOT because the turnaround is faster/easier (for not so
> experienced developers). Worst case we can patch it out of the base
> kernel I guess...
Me too. Now I understand John's patch entitled "[RFC] modpost: add option to
allow external modules to avoid taint". I doubt that it will be allowed
upstream, but I think that I will add it as a local commit.
I had failed to notice that the VB module was disabling lock checking, and I
ACKed a patch to rtlwifi that triggers a nested lock WARNING. Oh well, at least
the bug was not released into the wild yet.
Larry
On 12/16/2011 10:29 AM, Daniel Baluta wrote:
> Hello,
>
> On Fri, Dec 16, 2011 at 11:27 AM, Arend van Spriel <[email protected]> wrote:
>> To whoever may know,
>>
>> Upon loading our driver module I get the following message:
>>
>> kernel: [ 344.805106] Disabling lock debugging due to kernel taint
>>
>> What exactly are the criteria for tainting? Our driver locking strategy
>> is something we want to refactor and having lock debugging during that
>> transition may be a life safer.
>
> Is your driver GPL licensed?
>
> thanks,
> Daniel.
>
Not entirely:
MODULE_LICENSE("Dual BSD/GPL");
Gr. AvS
On Fri, 2011-12-16 at 09:48 -0500, Nick Bowler wrote:
> On 2011-12-16 14:58 +0100, Johannes Berg wrote:
> > Hmm. I wish OOT didn't disable lockdep, we do a lot of development with
> > modules OOT because the turnaround is faster/easier (for not so
> > experienced developers). Worst case we can patch it out of the base
> > kernel I guess...
>
> Indeed, but the good news is that we should finally be able to put this
> issue behind us soon(ish).
>
> https://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=9ec84acee1e221d99dc33237bff5e82839d10cc0
Oh. I just sent almost the same patch, oops!
johannes
On Fri, 2011-12-16 at 10:27 +0100, Arend van Spriel wrote:
> To whoever may know,
>
> Upon loading our driver module I get the following message:
>
> kernel: [ 344.805106] Disabling lock debugging due to kernel taint
>
> What exactly are the criteria for tainting? Our driver locking strategy
> is something we want to refactor and having lock debugging during that
> transition may be a life safer.
cat /proc/sys/kernel/tainted
johannes
On Fri, 2011-12-16 at 08:49 -0600, Larry Finger wrote:
> > + switch (flag) {
> > + case TAINT_CRAP:
> > + case TAINT_WARN:
> > + case TAINT_OOT_MODULE:
> > + break;
> > + default:
> > + if (__debug_locks_off())
> > + printk(KERN_WARNING
> > + "Disabling lock debugging due to kernel taint\n");
> > + }
> >
> > set_bit(flag,&tainted_mask);
> > }
>
> Yes. I like this patch a lot. Unfortunately, VirtualBox was a part of the
> decision to add the OOT taint. At least for that reason, this patch would not be
> accepted upstream. It is too bad that the Oracle people fought so hard to keep
> their module from setting TAINT_CRAP the way that GregKH wanted. That would have
> had fewer side effects for me.
I'm not sure -- I mean, it's one thing to identify OOT modules and
refuse to support them (and ignore lockdep reports with OOT set), but
it's another to just disable lockdep? I think?
johannes