Messages in this thread | | | Date | Sun, 19 Apr 2015 13:34:56 -0700 | Subject | Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking) | From | Linus Torvalds <> |
| |
On Sun, Apr 19, 2015 at 11:01 AM, Ingo Molnar <mingo@kernel.org> 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
| |