Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbbDSUe7 (ORCPT ); Sun, 19 Apr 2015 16:34:59 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:36031 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752501AbbDSUe5 (ORCPT ); Sun, 19 Apr 2015 16:34:57 -0400 MIME-Version: 1.0 In-Reply-To: <20150419180140.GA8934@gmail.com> References: <20150418232325.GA22411@roeck-us.net> <20150418234050.GA5987@roeck-us.net> <55330B32.4010907@roeck-us.net> <20150419033940.GA25145@debian> <20150419093112.GA6139@gmail.com> <5533B6D7.9050101@roeck-us.net> <20150419180140.GA8934@gmail.com> Date: Sun, 19 Apr 2015 13:34:56 -0700 X-Google-Sender-Auth: Rm9UNc9OwTH82URv4GxO2z9jib0 Message-ID: Subject: Re: qemu:arm test failure due to commit 8053871d0f7f (smp: Fix smp_call_function_single_async() locking) From: Linus Torvalds To: Ingo Molnar Cc: Guenter Roeck , Rabin Vincent , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , "Paul E. McKenney" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1541 Lines: 34 On Sun, Apr 19, 2015 at 11:01 AM, Ingo Molnar 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/