unexpected taint message

DISCUSSION Arend van Spriel 5 participants 14 messages Dec 16, 2011

lore

Share & tools

lore

Arend van Spriel

author

2011-12-16 09:27 UTC #0 lore raw

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

Daniel Baluta

2011-12-16 09:29 UTC #1 lore raw

Hello,

Quoted 9 lines · 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.

Is your driver GPL licensed?

thanks,
Daniel.

Arend van Spriel

author

2011-12-16 10:03 UTC #2 lore raw

Quoted 9 lines · Daniel Baluta

Hello,
Quoted 6 lines · 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

Quoted 9 lines

Quoted 3 lines
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

Johannes Berg

2011-12-16 12:30 UTC #3 lore raw

In reply to Arend van Spriel

Quoted 9 lines · 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.

cat /proc/sys/kernel/tainted

johannes

Larry Finger

2011-12-16 13:53 UTC #4 lore raw

Quoted 5 lines · Johannes Berg

Quoted 4 lines · Arend van Spriel
To whoever may know,
Upon loading our driver module I get the following message:

Quoted 7 lines

Quoted 5 lines
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

Johannes Berg

2011-12-16 13:59 UTC #5 lore raw

Quoted 17 lines · Larry Finger

Quoted 5 lines · Johannes Berg
Quoted 4 lines · Arend van Spriel
To whoever may know,
Upon loading our driver module I get the following message:
Quoted 7 lines
Quoted 5 lines
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:

Quoted 6 lines

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

Larry Finger

2011-12-16 14:13 UTC #6 lore raw

Quoted 21 lines · Johannes Berg

Quoted 20 lines · Larry Finger
Quoted 5 lines · Johannes Berg
Quoted 4 lines · Arend van Spriel
To whoever may know,
Upon loading our driver module I get the following message:
Quoted 7 lines
Quoted 5 lines
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.

Quoted 8 lines

Quoted 3 lines
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

Johannes Berg

2011-12-16 14:20 UTC #7 lore raw

Quoted 8 lines · Larry Finger

Quoted 4 lines
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:

kernel/panic.c +10 -2

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

Larry Finger

2011-12-16 14:49 UTC #8 lore raw

Quoted 16 lines · Johannes Berg

Quoted 8 lines · Larry Finger
Quoted 4 lines
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:

kernel/panic.c void add_taint(unsigned flag) · line 243

Quoted 4 lines

kernel/panic.c +0 -1

@@ -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())

Quoted 4 lines

kernel/panic.c +3 -1

-		printk(KERN_WARNING "Disabling lock debugging due to kernel taint\n");
+	switch (flag) {
+	case TAINT_CRAP:
+	case TAINT_WARN:

kernel/panic.c void add_taint(unsigned flag) · line 255

Quoted 10 lines

kernel/panic.c +7 -0

+	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

Johannes Berg

2011-12-16 14:51 UTC #9 lore raw

Quoted 11 lines · Larry Finger

Quoted 11 lines

kernel/panic.c +10 -0

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

Quoted 8 lines

Quoted 2 lines
  	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

Nick Bowler

2011-12-16 14:57 UTC #10 lore raw

In reply to Johannes Berg

Quoted 4 lines · Johannes Berg

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,

Signature · 1 line

Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Larry Finger

2011-12-16 14:57 UTC #11 lore raw

Quoted 10 lines · Nick Bowler

Quoted 4 lines · Johannes Berg
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

Johannes Berg

2011-12-16 14:58 UTC #12 lore raw

In reply to Nick Bowler

Quoted 10 lines · Nick Bowler

Quoted 4 lines · Johannes Berg
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

Arend van Spriel

author

2011-12-16 14:01 UTC #13 lore raw

In reply to Larry Finger

Quoted 3 lines · Larry Finger

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.

Quoted 2 lines

Larry

Gr. AvS