unexpected taint message

unexpected taint message

[Arend van Spriel]

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

Re: unexpected taint message

[Daniel Baluta]

Hello,

On Fri, Dec 16, 2011 at 11:27 AM, Arend van Spriel <arend@broadcom.com> 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.

Re: unexpected taint message

[Arend van Spriel]

On 12/16/2011 10:29 AM, Daniel Baluta wrote:
> Hello,
> 
> On Fri, Dec 16, 2011 at 11:27 AM, Arend van Spriel <arend@broadcom.com> 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

Re: unexpected taint message

[Johannes Berg]

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

Re: unexpected taint message

[Larry Finger]

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

Re: unexpected taint message

[Johannes Berg]

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

Re: unexpected taint message

[Arend van Spriel]

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

Re: unexpected taint message

[Larry Finger]

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

Re: unexpected taint message

[Johannes Berg]

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);
 }

Re: unexpected taint message

[Nick Bowler]

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/)

Re: unexpected taint message

[Larry Finger]

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

Re: unexpected taint message

[Johannes Berg]

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

Re: unexpected taint message

[Larry Finger]

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

Re: unexpected taint message

[Johannes Berg]

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