All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amol Grover <frextrite@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [Linux-kernel-mentees] [PATCH 2/2] events: callchain: Use RCU API to access RCU pointer
Date: Thu, 30 Jan 2020 15:44:51 +0530	[thread overview]
Message-ID: <20200130101451.GA11015@workstation-portable> (raw)
In-Reply-To: <20200130082321.GX14879@hirez.programming.kicks-ass.net>

On Thu, Jan 30, 2020 at 09:23:21AM +0100, Peter Zijlstra wrote:
> On Wed, Jan 29, 2020 at 05:19:09PM -0500, Joel Fernandes wrote:
> > On Wed, Jan 29, 2020 at 09:38:13PM +0530, Amol Grover wrote:
> > > callchain_cpus_entries is annotated as an RCU pointer.
> > > Hence rcu_dereference_protected or similar RCU API is
> > > required to dereference the pointer.
> > > 
> > > This fixes the following sparse warning
> > > kernel/events/callchain.c:65:17: warning: incorrect type in assignment
> 
> Seems silly to have this two patches; the first introduces the second
> issue, might as well fix it all in one go.
> 

Got it. I'll combine them into a single patch and re-send.

> Also look at the output of:
> 
>   git log --oneline kernel/events/
> 
> and then at your $subject.
> 
> > > Signed-off-by: Amol Grover <frextrite@gmail.com>
> > > ---
> > >  kernel/events/callchain.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > 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@joelfernandes.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.

Thanks
Amol

> IIRC even Alpha got the dependent write ordering right.
> 
> > >  	RCU_INIT_POINTER(callchain_cpus_entries, NULL);
> > >  	call_rcu(&entries->rcu_head, release_callchain_buffers_rcu);
> > >  }
> > > -- 
> > > 2.24.1
> > > 
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: Amol Grover <frextrite@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>,
	"Paul E . McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH 2/2] events: callchain: Use RCU API to access RCU pointer
Date: Thu, 30 Jan 2020 15:44:51 +0530	[thread overview]
Message-ID: <20200130101451.GA11015@workstation-portable> (raw)
In-Reply-To: <20200130082321.GX14879@hirez.programming.kicks-ass.net>

On Thu, Jan 30, 2020 at 09:23:21AM +0100, Peter Zijlstra wrote:
> On Wed, Jan 29, 2020 at 05:19:09PM -0500, Joel Fernandes wrote:
> > On Wed, Jan 29, 2020 at 09:38:13PM +0530, Amol Grover wrote:
> > > callchain_cpus_entries is annotated as an RCU pointer.
> > > Hence rcu_dereference_protected or similar RCU API is
> > > required to dereference the pointer.
> > > 
> > > This fixes the following sparse warning
> > > kernel/events/callchain.c:65:17: warning: incorrect type in assignment
> 
> Seems silly to have this two patches; the first introduces the second
> issue, might as well fix it all in one go.
> 

Got it. I'll combine them into a single patch and re-send.

> Also look at the output of:
> 
>   git log --oneline kernel/events/
> 
> and then at your $subject.
> 
> > > Signed-off-by: Amol Grover <frextrite@gmail.com>
> > > ---
> > >  kernel/events/callchain.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > 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@joelfernandes.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.

Thanks
Amol

> IIRC even Alpha got the dependent write ordering right.
> 
> > >  	RCU_INIT_POINTER(callchain_cpus_entries, NULL);
> > >  	call_rcu(&entries->rcu_head, release_callchain_buffers_rcu);
> > >  }
> > > -- 
> > > 2.24.1
> > > 

  reply	other threads:[~2020-01-30 10:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 16:08 [Linux-kernel-mentees] [PATCH 1/2] events: callchain: Annotate RCU pointer with __rcu Amol Grover
2020-01-29 16:08 ` Amol Grover
2020-01-29 16:08 ` [Linux-kernel-mentees] [PATCH 2/2] events: callchain: Use RCU API to access RCU pointer Amol Grover
2020-01-29 16:08   ` Amol Grover
2020-01-29 22:19   ` [Linux-kernel-mentees] " Joel Fernandes
2020-01-29 22:19     ` Joel Fernandes
2020-01-30  8:23     ` [Linux-kernel-mentees] " Peter Zijlstra
2020-01-30  8:23       ` Peter Zijlstra
2020-01-30 10:14       ` Amol Grover [this message]
2020-01-30 10:14         ` Amol Grover
2020-01-30 13:32         ` [Linux-kernel-mentees] " Peter Zijlstra
2020-01-30 13:32           ` Peter Zijlstra
2020-01-29 22:19 ` [Linux-kernel-mentees] [PATCH 1/2] events: callchain: Annotate RCU pointer with __rcu Joel Fernandes
2020-01-29 22:19   ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200130101451.GA11015@workstation-portable \
    --to=frextrite@gmail.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=joel@joelfernandes.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.