From: Amol Grover <frextrite@gmail.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>
Subject: Re: [Linux-kernel-mentees] [PATCH] events: Annotate parent_ctx with __rcu
Date: Thu, 13 Feb 2020 12:14:18 +0530 [thread overview]
Message-ID: <20200213064418.GA26550@workstation-portable> (raw)
In-Reply-To: <20200210170831.GB246160@google.com>
On Mon, Feb 10, 2020 at 12:08:31PM -0500, Joel Fernandes wrote:
> On Mon, Feb 10, 2020 at 10:17:27PM +0530, Amol Grover wrote:
> > On Mon, Feb 10, 2020 at 02:34:59PM +0100, Peter Zijlstra wrote:
> > > On Mon, Feb 10, 2020 at 06:29:48PM +0530, Amol Grover wrote:
> > > > On Mon, Feb 10, 2020 at 10:36:24AM +0100, Peter Zijlstra wrote:
> > > > > On Sat, Feb 08, 2020 at 08:16:49PM +0530, Amol Grover wrote:
> > >
> > > > > > @@ -3106,26 +3106,31 @@ static void ctx_sched_out(struct perf_event_context *ctx,
> > > > > > static int context_equiv(struct perf_event_context *ctx1,
> > > > > > struct perf_event_context *ctx2)
> > > > > > {
> > > > > > + struct perf_event_context *parent_ctx1, *parent_ctx2;
> > > > > > +
> > > > > > lockdep_assert_held(&ctx1->lock);
> > > > > > lockdep_assert_held(&ctx2->lock);
> > > > > >
> > > > > > + parent_ctx1 = rcu_dereference(ctx1->parent_ctx);
> > > > > > + parent_ctx2 = rcu_dereference(ctx2->parent_ctx);
>
> You can probably remove the earlier lockdep_assert_held(s) if you're going to
> use rcu_dereference_protected() here, since that would do the checking anyway.
>
Ah yes, I was thinking this aswell.
> > > > >
> > > > > Bah.
> > > > >
> > > > > Why are you fixing all this sparse crap and making the code worse?
> > > >
> > > > Hi Peter,
> > > >
> > > > Sparse is quite noisy and we need to eliminate false-positives, right?
> > >
> > > Dunno, I've been happy just ignoring it all.
>
> FWIW some of the sparse fixes Amol made recently did uncover so existing
> "bugs" :) (Not in perf but other code).
>
> > > > __rcu will tell the developer, this pointer could change and he needs to
> > > > take the required steps to make sure the code doesn't break.
> > >
> > > I know what it does; what I don't know is why you need to make the code
> > > worse. In paricular, __rcu doesn't mandate rcu_dereference(), esp. not
> > > when you're actually holding the write side lock.
> >
> > I might've misinterpreted the code. How does replacing rcu_dereference()
> > with
> > parent_ctx1 = rcu_dereference_protected(ctx1->parent_ctx,
> > lockdep_is_held(&ctx1->lock));
> > sound?
>
> FWIW, some maintainers do hate calling RCU APIs when write side lock is held.
> Evidently it does make the code readability a bit worse and I can see Peter's
> point of view because the existing code is correct. I leave it to you guys to
> decide how you want to handle it.
>
In that case, I think the code is fine as it is. Thank you for the review both!
Thanks
Amol
> thanks!
>
> - Joel
>
_______________________________________________
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: Joel Fernandes <joel@joelfernandes.org>
Cc: Peter Zijlstra <peterz@infradead.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 <madhuparnabhowmik10@gmail.com>,
"Paul E . McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH] events: Annotate parent_ctx with __rcu
Date: Thu, 13 Feb 2020 12:14:18 +0530 [thread overview]
Message-ID: <20200213064418.GA26550@workstation-portable> (raw)
In-Reply-To: <20200210170831.GB246160@google.com>
On Mon, Feb 10, 2020 at 12:08:31PM -0500, Joel Fernandes wrote:
> On Mon, Feb 10, 2020 at 10:17:27PM +0530, Amol Grover wrote:
> > On Mon, Feb 10, 2020 at 02:34:59PM +0100, Peter Zijlstra wrote:
> > > On Mon, Feb 10, 2020 at 06:29:48PM +0530, Amol Grover wrote:
> > > > On Mon, Feb 10, 2020 at 10:36:24AM +0100, Peter Zijlstra wrote:
> > > > > On Sat, Feb 08, 2020 at 08:16:49PM +0530, Amol Grover wrote:
> > >
> > > > > > @@ -3106,26 +3106,31 @@ static void ctx_sched_out(struct perf_event_context *ctx,
> > > > > > static int context_equiv(struct perf_event_context *ctx1,
> > > > > > struct perf_event_context *ctx2)
> > > > > > {
> > > > > > + struct perf_event_context *parent_ctx1, *parent_ctx2;
> > > > > > +
> > > > > > lockdep_assert_held(&ctx1->lock);
> > > > > > lockdep_assert_held(&ctx2->lock);
> > > > > >
> > > > > > + parent_ctx1 = rcu_dereference(ctx1->parent_ctx);
> > > > > > + parent_ctx2 = rcu_dereference(ctx2->parent_ctx);
>
> You can probably remove the earlier lockdep_assert_held(s) if you're going to
> use rcu_dereference_protected() here, since that would do the checking anyway.
>
Ah yes, I was thinking this aswell.
> > > > >
> > > > > Bah.
> > > > >
> > > > > Why are you fixing all this sparse crap and making the code worse?
> > > >
> > > > Hi Peter,
> > > >
> > > > Sparse is quite noisy and we need to eliminate false-positives, right?
> > >
> > > Dunno, I've been happy just ignoring it all.
>
> FWIW some of the sparse fixes Amol made recently did uncover so existing
> "bugs" :) (Not in perf but other code).
>
> > > > __rcu will tell the developer, this pointer could change and he needs to
> > > > take the required steps to make sure the code doesn't break.
> > >
> > > I know what it does; what I don't know is why you need to make the code
> > > worse. In paricular, __rcu doesn't mandate rcu_dereference(), esp. not
> > > when you're actually holding the write side lock.
> >
> > I might've misinterpreted the code. How does replacing rcu_dereference()
> > with
> > parent_ctx1 = rcu_dereference_protected(ctx1->parent_ctx,
> > lockdep_is_held(&ctx1->lock));
> > sound?
>
> FWIW, some maintainers do hate calling RCU APIs when write side lock is held.
> Evidently it does make the code readability a bit worse and I can see Peter's
> point of view because the existing code is correct. I leave it to you guys to
> decide how you want to handle it.
>
In that case, I think the code is fine as it is. Thank you for the review both!
Thanks
Amol
> thanks!
>
> - Joel
>
next prev parent reply other threads:[~2020-02-13 6:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-08 14:46 [Linux-kernel-mentees] [PATCH] events: Annotate parent_ctx with __rcu Amol Grover
2020-02-08 14:46 ` Amol Grover
2020-02-10 9:36 ` [Linux-kernel-mentees] " Peter Zijlstra
2020-02-10 9:36 ` Peter Zijlstra
2020-02-10 12:59 ` [Linux-kernel-mentees] " Amol Grover
2020-02-10 12:59 ` Amol Grover
2020-02-10 13:34 ` [Linux-kernel-mentees] " Peter Zijlstra
2020-02-10 13:34 ` Peter Zijlstra
2020-02-10 16:47 ` [Linux-kernel-mentees] " Amol Grover
2020-02-10 16:47 ` Amol Grover
2020-02-10 17:08 ` [Linux-kernel-mentees] " Joel Fernandes
2020-02-10 17:08 ` Joel Fernandes
2020-02-13 6:44 ` Amol Grover [this message]
2020-02-13 6:44 ` Amol Grover
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=20200213064418.GA26550@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=madhuparnabhowmik10@gmail.com \
--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.