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] [day] [month] [year] [list]

Message-ID: <CA+55aFyQhmxX-BAPXpNrwK2U4qjG8PCptykNAJUKMpHGe8=j3A@mail.gmail.com>
Date:	Mon, 20 Apr 2015 08:53:58 -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 10:39 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
>>
>> 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.
>
> Yes, and I don't disagree with such optimizations in principle (it
> allows less references to be taken in the fast path), but is it really
> safe?
>
> If a CPU is going down and we potentially race against that, and send
> off an IPI, the IPI might be 'in flight' for an indeterminate amount
> of time, especially on wildly non-deterministic hardware like virtual
> platforms.

Well, it should be easy enough to handle that race in the cpu
offlining: after the cpu is marked "not present", just call
flush_smp_call_function_queue(), In fact, I thought we did exactly
that - it's the reason for the "warn_cpu_offline" argument, isn't it)?

So I don't think there should be any real race.  Sure, the HW IPI
itself might be in flight, but from a sw perspective isn't all done.

No, I was talking about something even more optimistic - the CPU
number we optimisitcally loaded and sent an IPI to might be completely
bogus just because we loaded it using some unlocked sequence, and
maybe the memory got re-assigned. So it might not even be a CPU number
that is "stale", it could be entirely invalid.

And no, I don't claim that we should do this, I'm just saying that I
could imagine this being a valid thing to do. But it might be a good
idea to add a WARN_ON_ONCE() for now to find the users that are not
being clever like this, they are just being stupid and wrong-headed,
and sending IPI's to bogus CPU's not because they are doing really
subtle smart stuff, but just because they never noticed how stupid
they are..

                      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/