From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
a.p.zijlstra@chello.nl, paulus@samba.org, acme@redhat.com
Subject: Re: [PATCH RFC] perf: fix find_swevent_head() RCU lockdep splat
Date: Thu, 13 May 2010 16:43:27 -0700 [thread overview]
Message-ID: <20100513234327.GP2879@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100513205925.GE5377@nowhere>
On Thu, May 13, 2010 at 10:59:26PM +0200, Frederic Weisbecker wrote:
> On Thu, May 13, 2010 at 10:48:58PM +0200, Frederic Weisbecker wrote:
> > Paul, does that look good to you?
> > I've only compile tested. But if it's fine for you, I'll test
> > it for real and provide you a sane patch.
That would be very good!!! I believe that I have already more than proven
my ignorance of the perf_event code. ;-)
> > This version won't use more parameters than necessary in the
> > off case.
> >
> >
> > diff --git a/kernel/perf_event.c b/kernel/perf_event.c
> > index a4fa381..d765e48 100644
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -4066,19 +4066,36 @@ static inline u64 swevent_hash(u64 type, u32 event_id)
> > return hash_64(val, SWEVENT_HLIST_BITS);
> > }
> >
> > -static struct hlist_head *
> > -find_swevent_head(struct perf_cpu_context *ctx, u64 type, u32 event_id)
> > +static inline struct hlist_head *
> > +__find_swevent_head(struct swevent_hlist *hlist, u64 type, u32 event_id)
> > {
> > u64 hash;
> > - struct swevent_hlist *hlist;
>
>
>
> + if (!hlist)
> + return NULL;
>
>
>
> >
> > hash = swevent_hash(type, event_id);
> >
> > + return &hlist->heads[hash];
> > +}
> > +
> > +static inline struct hlist_head *
> > +find_swevent_head_rcu(struct perf_cpu_context *ctx, u64 type, u32 event_id)
> > +{
> > + struct swevent_hlist *hlist;
> > +
> > hlist = rcu_dereference(ctx->swevent_hlist);
This is appropriate if find_swevent_head_rcu() is always invoked in an
RCU read-side critical section. (Which at first glance does appear to
be the intent, just checking.)
> > - if (!hlist)
> > - return NULL;
> >
> > - return &hlist->heads[hash];
> > + return __find_swevent_head(hlist, type, event_id);
> > +}
> > +
> > +static inline struct hlist_head *
> > +find_swevent_head(struct perf_cpu_context *ctx, u64 type,
> > + u32 event_id, struct perf_event *event)
> > +{
> > + struct swevent_hlist *hlist;
> > +
> > + hlist = rcu_dereference_check(ctx->swevent_hlist,
> > + lockdep_is_held(&event->ctx->lock));
This could be invoked with either the event->ctx->lock held or in
an RCU read-side critical section. If this is always called with
the update-side lock held, you can (but don't need to) instead say:
hlist = rcu_dereference_protected(ctx->swevent_hlist,
lockdep_is_held(&event->ctx->lock));
This is slightly faster, as it drops the volatile casts. In many cases,
you won't care, but in case this code path needs ultimate performance.
Also I thought it was event->ctx.lock, but at this point I trust your eyes
more than my own. ;-)
Thanx, Paul
> > +
> > + return __find_swevent_head(hlist, type, event_id);
> > }
> >
> > static void do_perf_sw_event(enum perf_type_id type, u32 event_id,
> > @@ -4095,7 +4112,7 @@ static void do_perf_sw_event(enum perf_type_id type, u32 event_id,
> >
> > rcu_read_lock();
> >
> > - head = find_swevent_head(cpuctx, type, event_id);
> > + head = find_swevent_head_rcu(cpuctx, type, event_id);
> >
> > if (!head)
> > goto end;
> > @@ -4178,7 +4195,8 @@ static int perf_swevent_enable(struct perf_event *event)
> > perf_swevent_set_period(event);
> > }
> >
> > - head = find_swevent_head(cpuctx, event->attr.type, event->attr.config);
> > + head = find_swevent_head(cpuctx, event->attr.type,
> > + event->attr.config, event);
> > if (WARN_ON_ONCE(!head))
> > return -EINVAL;
> >
> >
> >
>
next prev parent reply other threads:[~2010-05-13 23:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 18:25 [PATCH RFC] perf: fix find_swevent_head() RCU lockdep splat Paul E. McKenney
2010-05-13 19:03 ` Frederic Weisbecker
2010-05-13 19:46 ` Paul E. McKenney
2010-05-13 20:26 ` Frederic Weisbecker
2010-05-13 20:48 ` Frederic Weisbecker
2010-05-13 20:59 ` Frederic Weisbecker
2010-05-13 23:43 ` Paul E. McKenney [this message]
2010-05-20 7:01 ` Frederic Weisbecker
2010-05-14 7:47 ` Peter Zijlstra
2010-05-20 7:04 ` Frederic Weisbecker
2010-05-14 7:44 ` Peter Zijlstra
2010-05-20 7:04 ` Frederic Weisbecker
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=20100513234327.GP2879@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).