Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2010602ybh; Sun, 8 Mar 2020 19:29:58 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsKgAWpC1P3uEltXvUUm07XObZGe0e0/vOh610WdOE/z+oh1uneA6yAq8wJuQd/K2pDiwAS X-Received: by 2002:aca:8d5:: with SMTP id 204mr9564490oii.141.1583720998704; Sun, 08 Mar 2020 19:29:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583720998; cv=none; d=google.com; s=arc-20160816; b=RhPaEa/qvECjEmNSyVf5PUsyITRjLR57aD214DzL26IQiU9GPQewIISmFG5dq2O48M KFnnMZvhKM1VETinc6KQjUA6Un6qlhkL69mxCj/PqWxLT2KyEXNkEpqNRXAOfBq9vJRA 98O9PPrSVpgWA5hUx2PDAvxZct40D3XTMYdxwlFwjIPFAOIJloySdSsJr2pBJI3vJ0fb Ti7c/oFG4i/zi6uYlZXb4K1sxq+/FX4rb11BehCUr10JFw+pPt7rqXC8idt85OKgR+Uj 4sJEcndZCGa2QNX/0OF4GRd228YcV7YN294l2I008ZsQ4lmqRm5WCVIKtJt/XD9uwRzf ZRDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=MgPGl4WGqzjXIxjyONhkK/WeBITYR/RYoUX96t6cY8Y=; b=bHVCmu48bKBMqCv2wjPC9wiCSb/KRN+csvd7Y8oes4mUPbxk55cHhlMaLExhf7GuDl TwqB4GDmwrmKk41VLcLqAbh2MnGIAfhpeZMXVND6ks8vszW5yDAGayz7z+ukTzz8sS6r l8fsVEiLVUs5GEwO17YEkc9e5xlMdkSrGQT6QUJ3nTZ4HTCBZkzoxMLgNc2XlTJ6v7Fj xh7GS4f1+EdCSoN2eGEVUq4qY8j77BqDwLlnUAiR1H/ogUo7hz+XNjUUIv3nYbfg09PA 4xoVKrE0msBGoUBnapP5WT/7FXkVE20nY74Lgm8iVHjRwSd11SXYJHOyVn34IxAClPek WHIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hNSdzBDo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si929809oig.197.2020.03.08.19.29.47; Sun, 08 Mar 2020 19:29:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hNSdzBDo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726617AbgCIC2d (ORCPT + 99 others); Sun, 8 Mar 2020 22:28:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:46504 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726363AbgCIC2c (ORCPT ); Sun, 8 Mar 2020 22:28:32 -0400 Received: from localhost (lfbn-ncy-1-985-231.w90-101.abo.wanadoo.fr [90.101.63.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CD74B20637; Mon, 9 Mar 2020 02:28:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583720912; bh=5Klv9i0gcwrEZVuZa+BIxD+FYTa6nxm4aw60GyHS0xI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hNSdzBDok5iJiJMWz5xJCqDSs2Kiw1Njm5O8MpOv68dsn0lXzL9Ly20CTyKNErqdj ire7Go761k+v5N+w7FDOgFMhXBJtxuKpw9trPEUy8Lq3o7H7uYTnOFSuJiYhlpLkhu zER5t9sviw+3mq1MeCu+MgQmxwblkqzSxeEpCk8E= Date: Mon, 9 Mar 2020 03:28:30 +0100 From: Frederic Weisbecker To: Alex Belits Cc: "mingo@kernel.org" , "peterz@infradead.org" , "rostedt@goodmis.org" , Prasun Kapoor , "tglx@linutronix.de" , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "catalin.marinas@arm.com" , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "linux-arch@vger.kernel.org" , "will@kernel.org" Subject: Re: [EXT] Re: [PATCH 11/12] task_isolation: kick_all_cpus_sync: don't kick isolated cpus Message-ID: <20200309022829.GB9615@lenoir> References: <4473787e1b6bc3cc226067e8d122092a678b63de.camel@marvell.com> <20200306153446.GC8590@lenoir> <7e0ce8988f4811e7453859e22654d2618557d9ab.camel@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e0ce8988f4811e7453859e22654d2618557d9ab.camel@marvell.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 08, 2020 at 06:48:43AM +0000, Alex Belits wrote: > On Fri, 2020-03-06 at 16:34 +0100, Frederic Weisbecker wrote: > > On Wed, Mar 04, 2020 at 04:15:24PM +0000, Alex Belits wrote: > > > From: Yuri Norov > > > > > > Make sure that kick_all_cpus_sync() does not call CPUs that are > > > running > > > isolated tasks. > > > > > > Signed-off-by: Alex Belits > > > --- > > > kernel/smp.c | 14 +++++++++++++- > > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/smp.c b/kernel/smp.c > > > index 3a8bcbdd4ce6..d9b4b2fedfed 100644 > > > --- a/kernel/smp.c > > > +++ b/kernel/smp.c > > > @@ -731,9 +731,21 @@ static void do_nothing(void *unused) > > > */ > > > void kick_all_cpus_sync(void) > > > { > > > + struct cpumask mask; > > > + > > > /* Make sure the change is visible before we kick the cpus */ > > > smp_mb(); > > > - smp_call_function(do_nothing, NULL, 1); > > > + > > > + preempt_disable(); > > > +#ifdef CONFIG_TASK_ISOLATION > > > + cpumask_clear(&mask); > > > + task_isolation_cpumask(&mask); > > > + cpumask_complement(&mask, &mask); > > > +#else > > > + cpumask_setall(&mask); > > > +#endif > > > + smp_call_function_many(&mask, do_nothing, NULL, 1); > > > + preempt_enable(); > > > } > > > > That looks very dangerous, the callers of kick_all_cpus_sync() want > > to > > sync all CPUs for a reason. You will rather need to fix the callers. > > All callers of this use this function to synchronize IPIs and icache, > and they have no idea if there is anything special about the state of > CPUs. If a task is isolated, this call would not be necessary because > the task is in userspace, and it would have to enter kernel for any of > that to become relevant but then it will have to switch from userspace > to kernel. At worst it is returning to userspace after entering > isolation or back in kernel running cleanup after isolation is broken > but before tsk_thread_flags_cache is updated. There will be nothing to > run on the same CPU because we have just left isolation, so task will > either exit or go back to userspace. > > Is there any reason for a race at that point? I can imagine several races: 1) The isolated task has set the cpumask but hasn't exited the kernel yet. If it still runs kernel code while kick_all_cpus_sync() has completed, we fail. 2) The isolated task is running do_exit() but the caller of kick_all_cpus_sync() still sees the target as part of the isolated mask. 3) The isolated task has just set the isolated cpumask and entered userspace but the caller still don't see the new value in the isolated cpumask, so it sends the IPI to the isolated CPU. Besides, any caller of kick_all_cpus_sync() is in its right to expect that everything preceding the call to that function is visible to all CPUs after that call. If you spare that IPI to an isolated CPU, what ensures it will see what it is supposed to once it calls do_exit() or prctl()? Is there a way we could fix the callers instead? For example synchronize_rcu() could be a replacement (it handles very well nohz_full CPUs), provided the callsites can sleep. It seems to be the case for __do_tune_cpucache() at least. flush_icache_range() is scarier I have to admit, doesn't look like it can sleep. > > Thanks. > > > > > EXPORT_SYMBOL_GPL(kick_all_cpus_sync); > > > > > > -- > > > 2.20.1 > > > > > -- > Alex