On 6/7/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote: > > Oh wait, the on_one_cpu() patch proposes on UP: > > +static inline int on_one_cpu(int cpu, void (*func)(void *info), void > *info, > + int retry, int wait) > +{ > > /* this needs a if (cpu == 0) check here, IMO */ > > + local_irq_disable(); > + func(info); > + local_irq_enable(); > + return 0; > > /* else WARN and return -EINVAL; */ > > +} > > which is broken without the suggested additions, IMHO > (this is what got me into this in the first place). There > _is_ a difference between on_each_cpu() and the > smp_call_function* semantics (as discussed on the other > thread -- gargh! my mistake for opening this discussion up > on so many threads), and in its current form on_one_cpu() > has quite confused semantics, trying to mix the two. I guess > on_one_cpu() would be better off simply being just an > atomic wrapper over smp_processor_id() and > smp_call_function_single() (which is the *real* issue that > needs solving in the first place), and do it well. >This is on UP, so (cpu == 0) is trivially true.
Yes, the caller code might derive the value for the cpu arg in such a manner to always only ever yield 0 on UP. OTOH, WARN_ON(!...)'s are often added for such assumptions that are understood to be trivially true. Note that a warning for cpu != 0 would be perfectly justified, we'd clearly want to flag such (errant) users. Anyway, I guess another problem being tackled here is avoding #ifdef CONFIG_SMP's to mask calls to smp_call_function* (and thus on_cpu()) in kernel code(?) Avoiding putting WARN_ON() in the UP cases could be useful to minimize noise, in that case. It (and smp_call_function*) could still return -EINVAL for the invalid cases, though. - 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/
