Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5017363ybv; Mon, 17 Feb 2020 10:28:48 -0800 (PST) X-Google-Smtp-Source: APXvYqyJaNI22HBxGXJMj8b2gbxy5ADAffB8bxADR9zrGhhyRBgZ005OmF9gNrHk1L+76lzYiXhH X-Received: by 2002:aca:3354:: with SMTP id z81mr200379oiz.129.1581964128746; Mon, 17 Feb 2020 10:28:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581964128; cv=none; d=google.com; s=arc-20160816; b=w4q02waX3dOfganml/aQZyHjUGFfSyHfoVROVPLapnEyTXC6333y/1cuVKG4O/QYuZ pvAnlefVpYDNB5Ru8pRhCTqjT2czwziDcYbNedQjCSatnuKVt+IUDLOGkUjA5rHQU3/y Bdz8RgT7rCVvhxrxHuE5En4HknkIXCamFo+oy+X8cMtgl5k3nHgZFLqFLM2DC1ftZvXt ayL9YtGKWStf174uUqIBRFa3MpnCPC331w8lN57H6vx38FM5yrqpE1fgvG2plbLkt2T/ l7UvVqgH3++grhbIUN6xIUx0BDrNtJq+Lt8ZN0C8wa5gTNgOsUvYyYNDZguqdVs9wyta UWEg== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=npMXAS3M05I8BmgjFBIhM2qWqr9QBZUMR+s/Cpa2lYc=; b=xYieOOeF3hBVFUdmzFNZCFvBwqU8joOas9i7y/4wJoHD0FM3ewv02+Bf6Cro2ftWTg yLnlzHaswtCBRoVovJ4se/qlOaHpKPhBIkCjZ/XWUoRVzus4nPeNpiKrG7C4wMlXzpeg ji16nicWJ3D7qPPUk1Qry62PzaxQzbpnPQnLqQDddCdtgMX/6dEEUtHJJB0rYeAgMeGD 1rHbfHHvzvmoiGA4AE+TIci2o6OvxMoJ9zECPcd6vzxEy5HzCfzUoC0lmqbIjH7efkKZ K0dtq5oC1GOW2L+3hE8f5gcaFkIF9JtuETQ7zis3h5hlOeyH+b9r1ejxFWLJOHSpQhed 2Erw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jtfA0j+j; 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 o6si6106094oie.193.2020.02.17.10.28.35; Mon, 17 Feb 2020 10:28:48 -0800 (PST) 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=jtfA0j+j; 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 S1729676AbgBQSQR (ORCPT + 99 others); Mon, 17 Feb 2020 13:16:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:38376 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728857AbgBQSQR (ORCPT ); Mon, 17 Feb 2020 13:16:17 -0500 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (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 340C52070B; Mon, 17 Feb 2020 18:16:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581963376; bh=6RH9h+HX+UEiJD8EUBKaev+n34U09RB7JZESfSpYDEE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=jtfA0j+j1J7Hr4gG1UnYK+WXv1HfNxPZmXShn1YCBVr3L+zBqNM4sjLSCHjEhc7Qk qt8PupyrSPu+s7eTRpv+MFljo5upBdWePJxkVs693yWBHJVVe2wV68/AjKYVK9yS0P fTtOWJaqU2uxc5M69z8fq0EzwmgizWEoDuYFSyK8= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 0708F352273C; Mon, 17 Feb 2020 10:16:16 -0800 (PST) Date: Mon, 17 Feb 2020 10:16:16 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, joel@joelfernandes.org Subject: Re: [PATCH tip/core/rcu 1/3] rcu-tasks: *_ONCE() for rcu_tasks_cbs_head Message-ID: <20200217181615.GP2935@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200215002446.GA15663@paulmck-ThinkPad-P72> <20200215002520.15746-1-paulmck@kernel.org> <20200217123851.GR14914@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200217123851.GR14914@hirez.programming.kicks-ass.net> 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 Mon, Feb 17, 2020 at 01:38:51PM +0100, Peter Zijlstra wrote: > On Fri, Feb 14, 2020 at 04:25:18PM -0800, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" > > > > The RCU tasks list of callbacks, rcu_tasks_cbs_head, is sampled locklessly > > by rcu_tasks_kthread() when waiting for work to do. This commit therefore > > applies READ_ONCE() to that lockless sampling and WRITE_ONCE() to the > > single potential store outside of rcu_tasks_kthread. > > > > This data race was reported by KCSAN. Not appropriate for backporting > > due to failure being unlikely. > > What failure is possible here? AFAICT this is (again) one of them > load-complare-against-constant-discard patterns that are impossible to > mess up. First, please keep in mind that this is RCU code. Rather uncomplicated for RCU, to be sure, but still RCU code. The failure modes are thus as follows: o I produce a patch for which KCSAN gives a legitimate warning, but this warning is obscured by a pile of other warnings. Yes, we should continue improving KCSAN's ability to adapt to the users desired compiler-optimization risk level, but in RCU's case that risk level is set quite low. In RCU, what others are calling false positives are therefore addressed. Yes, this does cost me a bit of work, but it is trivial compared to the work required to track down a real bug. o Someone optimizes or otherwise changes the wait/wakeup code, which inadvertently gives the compiler more scope for mischief. In short, within RCU, I am handling all KCSAN complaints. This is looking to be an extremely inexpensive insurance policy for RCU. Other subsystems are of course free to make their own tradeoffs, and subsystems having less-aggressive concurrency control might be well-advised to take a different path than the one I am taking. Thanx, Paul > > Signed-off-by: Paul E. McKenney > > --- > > kernel/rcu/update.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c > > index 6c4b862..a27df76 100644 > > --- a/kernel/rcu/update.c > > +++ b/kernel/rcu/update.c > > @@ -528,7 +528,7 @@ void call_rcu_tasks(struct rcu_head *rhp, rcu_callback_t func) > > rhp->func = func; > > raw_spin_lock_irqsave(&rcu_tasks_cbs_lock, flags); > > needwake = !rcu_tasks_cbs_head; > > - *rcu_tasks_cbs_tail = rhp; > > + WRITE_ONCE(*rcu_tasks_cbs_tail, rhp); > > rcu_tasks_cbs_tail = &rhp->next; > > raw_spin_unlock_irqrestore(&rcu_tasks_cbs_lock, flags); > > /* We can't create the thread unless interrupts are enabled. */ > > @@ -658,7 +658,7 @@ static int __noreturn rcu_tasks_kthread(void *arg) > > /* If there were none, wait a bit and start over. */ > > if (!list) { > > wait_event_interruptible(rcu_tasks_cbs_wq, > > - rcu_tasks_cbs_head); > > + READ_ONCE(rcu_tasks_cbs_head)); > > if (!rcu_tasks_cbs_head) { > > WARN_ON(signal_pending(current)); > > schedule_timeout_interruptible(HZ/10); > > -- > > 2.9.5 > >