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;
Date:   Tue, 18 Feb 2020 08:56:48 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
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: <20200218075648.GW14914@hirez.programming.kicks-ass.net>
References: <20200215002446.GA15663@paulmck-ThinkPad-P72>
 <20200215002520.15746-1-paulmck@kernel.org>
 <20200217123851.GR14914@hirez.programming.kicks-ass.net>
 <20200217181615.GP2935@paulmck-ThinkPad-P72>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200217181615.GP2935@paulmck-ThinkPad-P72>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Feb 17, 2020 at 10:16:16AM -0800, Paul E. McKenney wrote:
> 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" <paulmck@kernel.org>
> > > 
> > > 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.

I just took offence at the Changelog wording. It seems to suggest there
actually is a problem, there is not.