linux-kernel - Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 19 Apr 2015 13:34:56 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Guenter Roeck <linux@...ck-us.net>, Rabin Vincent <rabin@....in>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ibm.com>
Subject: Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix
 smp_call_function_single_async() locking)

On Sun, Apr 19, 2015 at 11:01 AM, Ingo Molnar <mingo@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/