All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>, Greg KH <gregkh@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	LTP <ltp-list@lists.sourceforge.net>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] lockdep: choose to continue lock debugging despite taint
Date: Fri, 10 Apr 2009 14:15:15 +0200	[thread overview]
Message-ID: <20090410121515.GP21506@elte.hu> (raw)
In-Reply-To: <1239312460-13396-2-git-send-email-fweisbec@gmail.com>


* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> Lockdep is disabled after any kernel taints. This might be 
> convenient to ignore bad locking issues which sources come from 
> outside the kernel tree. Nevertheless, it might be a frustrating 
> experience for the staging developers or anyone who might develop 
> a kernel that happens to be tainted.

Good point. Not having lockdep coverage for drivers/staging/ just 
prolongs their transition - not good.

But instead of this:

>  void add_taint(unsigned flag)
>  {
> +#ifndef CONFIG_LOCKDEP_IGNORE_TAINT
>  	/*
>  	 * Can't trust the integrity of the kernel anymore.
>  	 * We don't call directly debug_locks_off() because the issue
> @@ -220,6 +221,7 @@ void add_taint(unsigned flag)
>  	 */
>  	if (xchg(&debug_locks, 0))
>  		printk(KERN_WARNING "Disabling lockdep due to kernel taint\n");
> +#endif

I'd suggest to not do the debug_locks_off() call if TAINT_CRAP. I.e. 
something like:

	if (!(flag & TAINT_CRAP) && debug_locks_off())
		printk(...);

will do the trick.

	Ingo

  reply	other threads:[~2009-04-10 12:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-09 21:27 [PATCH 1/2] lockdep: warn about lockdep disabling after kernel taint Frederic Weisbecker
2009-04-09 21:27 ` [PATCH 2/2] lockdep: choose to continue lock debugging despite taint Frederic Weisbecker
2009-04-10 12:15   ` Ingo Molnar [this message]
2009-04-10 13:38     ` Frederic Weisbecker
2009-04-10 13:45       ` Ingo Molnar
2009-04-11  1:15         ` Frederic Weisbecker
2009-04-11  1:37           ` Frederic Weisbecker
2009-04-12 14:09             ` Ingo Molnar
2009-04-11  1:17         ` [PATCH 1/2 v2] lockdep: warn about lockdep disabling after kernel taint Frederic Weisbecker
2009-04-12 14:45           ` [tip:core/urgent] " Frederic Weisbecker
2009-04-11  1:17         ` [PATCH 2/2 v2] lockdep: continue lock debugging despite some taints Frederic Weisbecker
2009-04-12 14:45           ` [tip:core/urgent] " Frederic Weisbecker
2009-04-10 12:12 ` [PATCH 1/2] lockdep: warn about lockdep disabling after kernel taint Ingo Molnar
2009-04-10 13:34   ` Frederic Weisbecker
2009-04-10 13:38     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090410121515.GP21506@elte.hu \
    --to=mingo@elte.hu \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.