All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Jiri Kosina <jkosina@suse.cz>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	WANG Cong <xiyou.wangcong@gmail.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Tejun Heo <tj@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] base firmware: Fix BUG from sysfs attributes change in commit a2db6842873c8e5a70652f278d469128cb52db70
Date: Sun, 14 Mar 2010 07:59:52 +0100	[thread overview]
Message-ID: <20100314065952.GA24489@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1003132131470.3719@i5.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 13 Mar 2010, Eric W. Biederman wrote:
> > 
> > It also only affects those fairly rare lockdep users as well, and the only
> > affect is to throw a nasty warning message.  Isn't lockdep all about throwing
> > nasty warning messages?
> 
> Hmm. The report has that "BUG: " message in it (and in the subject line), 
> but you're right - it ends up being just a warning, not actually a real 
> BUG() (which is a machine killer).
> 
> So yeah - it's not as bad as I thought. Sorry.
> 
> [ And that "BUG:" in turn seems to be due to Ingo for some reason wanting 
>   to confuse BUG_ON() messages (which have that "BUG: " prefix thing) with 
>   whatever warning conditions he adds.
> 
>   Our warnings used to have that bug too (see commit 8f53b6fcc4: "Don't 
>   call a warnign a bug. It's a warning.").
> 
>   Ingo: can we agree to not put "BUG: " messages in warnings, ok? It may 
>   be a bug (lower-case) that triggers them, but that whole "BUG()" thing 
>   has it's own semantics with rather more serious consequences than some 
>   warning that lets things continue.

Sure - will change those too over to the "INFO: " pattern we've been using for 
some time. All new warnings that come via our trees use 'INFO: ', the 'BUG: ' 
ones are there for historic reasons.

There's a few that are external to lockdep and are likely fatal conditions:

	printk(  "[ BUG: bad unlock balance detected! ]\n");
	printk(  "[ BUG: bad contention detected! ]\n");
	printk(  "[ BUG: held lock freed! ]\n");
	printk(  "[ BUG: lock held at task exit time! ]\n");

(these things often tend to cause hangs/crashes later on.)

and then there's a few that are mostly internal to lockdep, and should never 
be fatal:

		printk("BUG: MAX_STACK_TRACE_ENTRIES too low!\n");
		printk("BUG: MAX_LOCKDEP_KEYS too low!\n");
		printk("BUG: MAX_LOCKDEP_ENTRIES too low!\n");
		printk("BUG: MAX_LOCKDEP_CHAINS too low!\n");
		printk("BUG: key %p not in .data!\n", key);
		printk("BUG: MAX_LOCKDEP_SUBCLASSES too low!\n");
		printk("BUG: MAX_LOCK_DEPTH too low!\n");

[ there's rare exceptions - i've seen 'BUG: key' + real crash on a few occasions,
  when the warning was caused by memory corruption. But typically the warning 
  is not fatal, and this is what matters to the severity of the message. ]

So i'm wondering whether we should/could keep those first four with a 'BUG: ' 
message, as lockdep wont crash the machine in the BUG() fashion. The other 7 
should definitely be less alarming messages.

	Ingo

  reply	other threads:[~2010-03-14  7:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-13 19:36 [PATCH] base firmware: Fix BUG from sysfs attributes change in commit a2db6842873c8e5a70652f278d469128cb52db70 Larry Finger
2010-03-13 22:32 ` Linus Torvalds
2010-03-13 22:39   ` Jiri Kosina
2010-03-13 22:57     ` Linus Torvalds
2010-03-14  3:57       ` Eric W. Biederman
2010-03-14  5:46         ` Linus Torvalds
2010-03-14  6:59           ` Ingo Molnar [this message]
2010-03-14 17:20             ` Linus Torvalds
2010-03-14 18:11           ` Greg KH
2010-03-14 18:30             ` Eric W. Biederman
2010-03-14 18:38               ` Greg KH
2010-03-14 10:49         ` Wolfram Sang
2010-03-14 18:04           ` Linus Torvalds
2010-03-14 18:07             ` Linus Torvalds
2010-03-14 19:08             ` Eric W. Biederman
2010-03-15  0:48               ` Wolfram Sang
2010-03-15  0:20             ` Wolfram Sang
2010-03-15  0:29             ` [PATCH] init dynamic bin_attribute structures Wolfram Sang
2010-03-15  0:29               ` Wolfram Sang
2010-03-15 10:00               ` Jiri Kosina
2010-03-15 10:00                 ` Jiri Kosina
2010-03-15 10:12                 ` [rtc-linux] " Wolfram Sang
2010-03-15 10:12                   ` Wolfram Sang
2010-03-15 18:47                 ` Linus Torvalds
2010-03-15 18:47                   ` Linus Torvalds
2010-03-13 22:55   ` [PATCH] base firmware: Fix BUG from sysfs attributes change in commit a2db6842873c8e5a70652f278d469128cb52db70 Larry Finger

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=20100314065952.GA24489@elte.hu \
    --to=mingo@elte.hu \
    --cc=Larry.Finger@lwfinger.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xiyou.wangcong@gmail.com \
    /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.