Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking)

[Linus Torvalds]

On Sun, Apr 19, 2015 at 11:01 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> That's all fine and good, but why is an IPI sent to a non-existent
> CPU? It's not like we don't know which CPU is up and down.

I agree that the qemu-arm behavior smells like a bug, plain and
simple. Nobody sane should send random IPI's to CPU's that they don't
even know are up or not.

That said, I could imagine that we would have some valid case where we
just do a cross-cpu call to (for example) do lock wakeup, and the code
would use some optimistic algorithm that prods the CPU after the lock
has been released, and there could be some random race where the lock
data structure has already been released (ie imagine the kind of
optimistic unlocked racy access to "sem->owner" that we discussed as
part of the rwsem_spin_on_owner() thread recently).

So I _could_ imagine that somebody would want to do optimistic "prod
other cpu" calls that in all normal cases are for existing cpus, but
could be racy in theory.

It doesn't sound like the qemu-arm case is that kind of situation,
though. That one just sounds like a stupid "let's send an ipi to a cpu
whether it exists or not".

But Icommitted it without any new warning, because I could in theory
see it as being a valid use.

                           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/