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?
(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
