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: <20090313103828.GB31094@elte.hu>
Date:	Fri, 13 Mar 2009 11:38:28 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Jan Beulich <jbeulich@...ell.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [tip:core/ipi] generic-ipi: eliminate spurious
	pointlessWARN_ON()s


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Fri, 2009-03-13 at 09:21 +0000, Jan Beulich wrote:
> > >>> Peter Zijlstra <peterz@...radead.org> 13.03.09 09:54 >>>
> > >Wouldn't leaving them in place but changing them to:
> > >
> > >WARN_ON(irqs_disabled() && system_state == SYSTEM_RUNNING);
> > >
> > >be clearer?
> > 
> > I don't think that would be precise: system_state gets set to
> > SYSTEM_RUNNING much later than APs get brought up (i.e. there are
> > cases where the WARN_ON()s could validly trigger with SYSTEM_BOOTING),
> > and also doesn't cover states > SYSTEM_RUNNING (where, again, after
> > perhaps having brought down all APs the warnings could become pointless,
> > but the warnings could be meaningful as long as there are still some APs
> > online).
> > 
> > While from an abstract code reading perspective your suggestion might
> > seem reasonable, the changed placement really reflects what the warning
> > is trying to warn about - a potential deadlock which cannot occur under
> > the conditions filtered out by conditionals the warnings were moved
> > beyond.
> 
> How about?
> 
> WARN_ON_ONCE(irqs_disabled() && !oops_in_progress)

ok, that's indeed better - i've done that - see the upcoming 
commit messages in this thread.

I also changed all of panic() to be covered by oops_in_progress 
- see the other commit. Eric: that should make kexec [a tiny 
bit] more robust too, agreed?

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ