linux-kernel - Re: [PATCH] UP: smp_call_function_single() must warn on irqs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0707181016380.32074@cselinux1.cse.iitk.ac.in>
Date:	Wed, 18 Jul 2007 10:19:29 +0530 (IST)
From:	Satyam Sharma <ssatyam@....iitk.ac.in>
To:	Al Viro <viro@....linux.org.uk>
cc:	Uwe Kleine-Konig <ukleinek@...ormatik.uni-freiburg.de>,
	Avi Kivity <avi@...ranet.com>, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>
Subject: Re: [PATCH] UP: smp_call_function_single() must warn on irqs_disabled()

On Wed, 18 Jul 2007, Satyam Sharma wrote:

> On Wed, 18 Jul 2007, Al Viro wrote:
> 
> > On Wed, Jul 18, 2007 at 01:24:46AM +0200, Uwe Kleine-Konig wrote:
> > > [...]
> > > a52b1752c07 introduces usage of the WARN_ON macro in <linux/smp.h>, but
> > > doesn't pull in <linux/kernel.h>.  (<asm/bug.h> is not enough, at least
> > > for arm, because WARN_ON uses printk there.)
> > > 
> > > The obvious options are:
> > > 
> > > 1) include <linux/kernel.h> in <linux/smp.h>, maybe conditioned by !SMP
> > > 2) include <linux/kernel.h> in all includers of <linux/smp.h>
> > > 3) remove the WARN_ONs introduced by a52b1752c07.
> > > [...]
> > 
> > 4) turn the sucker into macro
> 
> 
> I think that warning is incorrect anyway ... and I'm to blame
> for that. What happened is that I had earlier (month or two back,
> _before_ the recent change in smp_call_function_single() semantics)
> submitted a patch that put an unconditional WARN_ON(1) in this
> function for UP -- in those days, both the smp_call_function*
> variants were illegal on the current CPU itself.
> ( http://lkml.org/lkml/2007/6/7/262 )
> 
> Then recently, Andi / Avi proposed the new semantics for
> smp_call_function_single() to allow it to just execute the given
> function on current CPU as well -- smp_call_function() semantics
> were left unchanged, so as not to break stuff like smp_send_stop().
> 
> I think I got confused and recommended the (cpuid != 0) warning,
> but I don't really think it is necessary with new semantics --
> sorry about this, Avi.
> 
> OTOH, the function _should_ include a WARN_ON, but for a different
> condition -- irqs_disabled(), as explained in changelog below.

But on third thoughts, we shouldn't be executing that function locally
for UP if cpuid != 0 anyway, so my earlier suggestion wasn't really
erroneous ... perhaps *both* those warnings are required (well, the
irqs_disabled() one definitely is, at least).
-
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/