lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep

tip:core/locking tip-bot for Peter Zijlstra 5 participants 8 messages Dec 6, 2011

Share & tools

tip-bot for Peter Zijlstra

author

2011-12-06 09:38 UTC #0 lore raw

Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100

lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep

It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:

- bin-only modules can cause various instabilities in their and in unrelated kernel code

- they are impossible to debug for kernel developers

- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.

Signed-off-by Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/n/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

---
 kernel/panic.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

kernel/panic.c +10 -2

index b2659360..1b83fd8 100644
@@ -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_FIRMWARE_WORKAROUND:
+		break;
+
+	default:
+		if (__debug_locks_off())
+			printk(KERN_WARNING "Disabling lock debugging due to kernel taint\n");
+	}
 
 	set_bit(flag, &tainted_mask);
 }

Nick Bowler

2011-12-06 15:14 UTC #1 lore raw

Quoted 14 lines · tip-bot for Peter Zijlstra

Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:

Quoted 7 lines

- bin-only modules can cause various instabilities in their and in unrelated kernel code
- they are impossible to debug for kernel developers
- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.

This is all bogus. We have a proprietary module taint for the above. Out of tree does not mean "bin-only", "non-GPL" or anything else like that. If the intent is to tell out of tree, GPL module developers to fuck off and die, then just go all the way and delete support for out of tree modules from Kbuild. May as well go further and just prevent the kernel from loading such modules outright, too.

Don't gag developers by arbitrarily disabling kernel debugging
functionality: functionality that they can use to debug their *GPL* modules.

Signature · 1 line

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

Ben Hutchings

2011-12-06 15:31 UTC #2 lore raw

Quoted 30 lines · Nick Bowler

Quoted 14 lines · tip-bot for Peter Zijlstra
Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:
Quoted 7 lines
- bin-only modules can cause various instabilities in their and in unrelated kernel code
- they are impossible to debug for kernel developers
- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.
This is all bogus. We have a proprietary module taint for the above. Out of tree does not mean "bin-only", "non-GPL" or anything else like that. If the intent is to tell out of tree, GPL module developers to fuck off and die, then just go all the way and delete support for out of tree modules from Kbuild. May as well go further and just prevent the kernel from loading such modules outright, too.

Quoted 3 lines

Don't gag developers by arbitrarily disabling kernel debugging
functionality: functionality that they can use to debug their *GPL* modules.

I totally agree; *I* wanted to keep lockdep enabled for (GPL-compatible) OOT modules.

Ben.

Signature · 2 lines

Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

Alan Cox

2011-12-06 15:41 UTC #3 lore raw

In reply to Nick Bowler

Quoted 18 lines · On Tue, 6 Dec 2011 10:13:45 -0500 Nick Bowler <[email protected]> wrote:

Quoted 17 lines · tip-bot for Peter Zijlstra
Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:
- bin-only modules can cause various instabilities in their and in unrelated kernel code

Quoted 8 lines

Quoted 4 lines
- they are impossible to debug for kernel developers
- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.
This is all bogus. We have a proprietary module taint for the above. Out of tree does not mean "bin-only", "non-GPL" or anything else like that.

It also stops people developing drivers of their own who are not building them in the kernel tree currently (eg when I'm building tests of the GMA500 graphics driver). This is a ludicrous patch and should be reverted

Alan

Ben Hutchings

2011-12-06 15:44 UTC #4 lore raw

Quoted 26 lines · Alan Cox

Quoted 23 lines · On Tue, 6 Dec 2011 10:13:45 -0500 Nick Bowler <[email protected]> wrote:
Quoted 21 lines · tip-bot for Peter Zijlstra
Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:
- bin-only modules can cause various instabilities in their and in unrelated kernel code
- they are impossible to debug for kernel developers
- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.

Quoted 8 lines

Quoted 3 lines
This is all bogus. We have a proprietary module taint for the above. Out of tree does not mean "bin-only", "non-GPL" or anything else like that.
It also stops people developing drivers of their own who are not building them in the kernel tree currently (eg when I'm building tests of the GMA500 graphics driver). This is a ludicrous patch and should be reverted

My change to set TAINT_OOT_MODULE had the (unintentional) effect of disabling lockdep for OOT modules. I subsequently proposed to change that (while adding taint flags to lockdep output). This patch doesn't make any change either way.

Ben.

Signature · 2 lines

Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

Ingo Molnar

2011-12-06 17:45 UTC #5 lore raw

In reply to Alan Cox

Quoted 26 lines · Alan Cox

Quoted 23 lines · On Tue, 6 Dec 2011 10:13:45 -0500 Nick Bowler <[email protected]> wrote:
Quoted 21 lines · tip-bot for Peter Zijlstra
Commit-ID:  df754e6af2f237a6c020c0daff55a1a609338e31
Gitweb:     http://git.kernel.org/tip/df754e6af2f237a6c020c0daff55a1a609338e31
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Mon, 14 Nov 2011 13:13:49 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 6 Dec 2011 08:16:47 +0100
lockdep, bug: Exclude TAINT_FIRMWARE_WORKAROUND from disabling lockdep
It's unlikely that TAINT_FIRMWARE_WORKAROUND causes false lockdep messages, so do not disable lockdep in that case. We still want to keep lockdep disabled in the TAINT_OOT_MODULE case:
- bin-only modules can cause various instabilities in their and in unrelated kernel code
- they are impossible to debug for kernel developers
- they also typically do not have the copyright license permission to link to the GPL-ed lockdep code.

Quoted 8 lines

Quoted 3 lines
This is all bogus. We have a proprietary module taint for the above. Out of tree does not mean "bin-only", "non-GPL" or anything else like that.
It also stops people developing drivers of their own who are not building them in the kernel tree currently (eg when I'm building tests of the GMA500 graphics driver). This is a ludicrous patch and should be reverted

That patch is already upstream, it was done via the module tree:

2449b8ba0745: module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

lockdep disabling itself defensively is an effect of that change. The commit you replied to here does not change that aspect in any way.

My primary worry is to not have lockdep active when there's binary modules in a system - can TAINT_OOT_MODULE be set but TAINT_PROPRIETARY_MODULE not set for non-GPL modules?

If not, and if TAINT_OOT_MODULE set and TAINT_PROPRIETARY_MODULE cleared guarantees the GPL-ness of the module then i have no problem with keeping lockdep active in that case.

Thanks,

Ingo

Alan Cox

2011-12-06 17:51 UTC #6 lore raw

Quoted 3 lines

My primary worry is to not have lockdep active when there's binary modules in a system - can TAINT_OOT_MODULE be set but TAINT_PROPRIETARY_MODULE not set for non-GPL modules?

Yes. I imagine anyone wanting to use lockdep with binary modules would just lie anyway.

Quoted 3 lines

If not, and if TAINT_OOT_MODULE set and TAINT_PROPRIETARY_MODULE cleared guarantees the GPL-ness of the module then i have no problem with keeping lockdep active in that case.

Insofar as nobody is making their code line about licenses.

Alan

Ingo Molnar

2011-12-06 18:15 UTC #7 lore raw

Quoted 4 lines · Alan Cox

Quoted 3 lines
My primary worry is to not have lockdep active when there's binary modules in a system - can TAINT_OOT_MODULE be set but TAINT_PROPRIETARY_MODULE not set for non-GPL modules?

Quoted 8 lines

Yes. I imagine anyone wanting to use lockdep with binary modules would just lie anyway.
Quoted 3 lines
If not, and if TAINT_OOT_MODULE set and TAINT_PROPRIETARY_MODULE cleared guarantees the GPL-ness of the module then i have no problem with keeping lockdep active in that case.
Insofar as nobody is making their code line about licenses.

Fair enough - so i agree that we can allow OOT_MODULE's with lockdep and thus revert the lockdep-disabling effect of:

2449b8ba0745: module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

Thanks,

Ingo