linux-kernel - Re: unexpected taint message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1324043939.3429.2.camel@jlt3.sipsolutions.net>
Date:	Fri, 16 Dec 2011 14:58:59 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Arend van Spriel <arend@...adcom.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: unexpected taint message

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/