On Tue, Feb 17, 2009 at 08:28:10PM +0100, Oleg Nesterov wrote:
> On 02/17, Nick Piggin wrote:
> >
> > How's this?
>
> To me, this patch makes the code much more clean/understandable.
>
> And imho it is very good it removes smp_read_barrier_depends()s
> which (I think) were just wrong.
>
>
> But I still have the question,
>
> > Does any architecture actually needs barriers? For the initiator I
> > could see it, but for the handler I would be surprised. The other
> > thing we could do for simplicity is just to require that a full
> > barrier is required before generating an IPI, and after receiving an
> > IPI. We can't just do that in generic code without auditing
> > architectures. There have been subtle hangs here on some archs in
> > the past.
>
> OK, so we add the barrier here:
>
> > @@ -104,6 +111,14 @@ void generic_smp_call_function_interrupt
> > int cpu = get_cpu();
> >
> > /*
> > + * Ensure entry is visible on call_function_queue after we have
> > + * entered the IPI. See comment in smp_call_function_many.
> > + * If we don't have this, then we may miss an entry on the list
> > + * and never get another IPI to process it.
> > + */
> > + smp_mb();
>
> But, any arch which needs this barrier should also call mb() in, say,
> smp_reschedule_interrupt() path. Otherwise we can miss TIF_NEED_RESCHED
> after return from the handler.
>
> So the question is: is there any arch which surely needs this barrier?
>
> IOW,
> int COND;
>
> void smp_xxx_interrupt(regs)
> {
> BUG_ON(!COND);
> }
>
> COND = 1;
> mb();
> smp_send_xxx(cpu);
>
> can we really hit the BUG_ON() above on some arch?
If all of the above is executed by the same task, tripping the BUG_ON()
means either a compiler or CPU bug.
Thanx, Paul
> (but in any case I agree, it is better to be safe and add the barrier
> like this patch does).
>
> Oleg.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
