Re: [PATCH] lockdep: disable lock debugging when kernel statebecomes untrusted
From: Andrew Morton
Date: Sun Aug 13 2006 - 21:49:18 EST
On Mon, 14 Aug 2006 03:09:54 +0200
Voluspa <lista1@xxxxxxxxx> wrote:
> On 2006-07-10 21:02:59 git-commits-head received:
> > commit 2c16e9c888985761511bd1905b00fb271169c3c0
> > tree e17756b3ed27b0f4953547c39cf46864cdd6f818
> > parent e54695a59c278b9ff48cd4b263da7a1d392f5061
> > author Arjan van de Ven Mon, 10 Jul 2006
> > 18:45:42 -0700 committer Linus Torvalds Tue, 11
> > Jul 2006 03:24:27 -0700
> > [PATCH] lockdep: disable lock debugging when kernel state becomes
> > untrusted
> > Disable lockdep debugging in two situations where the integrity of the
> > kernel no longer is guaranteed: when oopsing and when hitting a
> > tainting-condition. The goal is to not get weird lockdep traces that
> > don't make sense or are otherwise undebuggable, to not waste time.
> > Lockdep assumes that the previous state it knows about is valid to
> > operate, which is why lockdep turns itself off after the first
> > violation it reports, after that point it can no longer make that
> > assumption.
> > A kernel oops means that the integrity of the kernel compromised; in
> > addition anything lockdep would report is of lesser importance than the
> > oops.
> > All the tainting conditions are of similar integrity-violating nature
> > and also make debugging/diagnosing more difficult.
> On my x86_64 notebook I need ndiswrapper. No but-s, if-s or anything-s.
> Period. I also have to work outside of X in a clean terminal (console).
> This patch unfortunately creates a 'pipe' directly from
> /var/log/messages to the screen. So if I work in a textbased program,
> and something happens in the log, the program gets a broken interface.
> Programs that simultaniously output to the log becomes unusable.
> It is also darn irritating when text strings materializes at the shell
> Once the 'pipe' is established (by tainting) it can not be reverted by
> eg rmmod ndiswrapper.
> I haven't even enabled any lockdep debugging:
That would appear to be a bug. debug_locks_off() is running
console_verbose() waaaay after the locking selftest code has completed.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/