Re: [PATCH] UP: smp_call_function_single() must warn on irqs_disabled()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux