linux-kernel - Re: [PATCH 2/2] events: callchain: Use RCU API to access RCU pointer

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: <20200130133248.GW14914@hirez.programming.kicks-ass.net>
Date:   Thu, 30 Jan 2020 14:32:48 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Amol Grover <frextrite@...il.com>
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Madhuparna Bhowmik <madhuparnabhowmik04@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH 2/2] events: callchain: Use RCU API to access RCU pointer

On Thu, Jan 30, 2020 at 03:44:51PM +0530, Amol Grover wrote:
> > > > diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
> > > > index f91e1f41d25d..a672d02a1b3a 100644
> > > > --- a/kernel/events/callchain.c
> > > > +++ b/kernel/events/callchain.c
> > > > @@ -62,7 +62,8 @@ static void release_callchain_buffers(void)
> > > >  {
> > > >  	struct callchain_cpus_entries *entries;
> > > >  
> > > > -	entries = callchain_cpus_entries;
> > > > +	entries = rcu_dereference_protected(callchain_cpus_entries,
> > > > +					    lockdep_is_held(&callchain_mutex));
> > > 
> > > 
> > > Reviewed-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> > 
> > Do we really need that smp_read_barrier_depends() here? Then again, I
> > don't suppose this is a fast path.
> > 
> 
> rcu_dereference_protected is actually a lightweight API and IIRC it
> omits the READ_ONCE() and hence the memory barriers.

Oh argh, indeed. I suppose I should've had more tea this morning.