From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] markers: fix unregister bug and reenter bug
Date: Mon, 29 Sep 2008 23:38:36 -0400 [thread overview]
Message-ID: <20080930033836.GA12733@Krystal> (raw)
In-Reply-To: <48E18389.3030202@cn.fujitsu.com>
* Lai Jiangshan (laijs@cn.fujitsu.com) wrote:
> Mathieu Desnoyers wrote:
> > Hi Lai,
> >
> > I'll have to nack this fix :
> >
> > One fix I already posted makes sure every marker unregister callers call
> > synchronize_sched() _at some point_ before module unload. It thus makes
> > sure we can do batch unregistration without doing multiple
> > synchronize_sched calls.
>
> 1) the new API marker_synchronize_unregister() is ugly, it separate one thing
> into two steps.
> user have to remember to call marker_synchronize_unregister() and have
> to know what he can do and what he can't do before
> marker_synchronize_unregister().
>
Hum, yes it does separate unregistration and synchronization in two
steps for a very precise purpose : I don't want unregistration of 100
markers to take ~30 seconds on a heavily loaded machine.
> 2) IMO, synchronous code is better than asynchronous in non-critical-path.
> we need synchronize_sched() for free(old).
>
free(old) is only done in call_rcu. the rcu callback is forced by a
rcu_barrier() if two consecutive operations are done on the same
marker.
> you fixes haven't fix the reenter bug.
>
I don't see any reentrancy bug here. Have you actually experienced such
an issue ? Can you give me an example of a bogus execution trace
(step-by-step operations) ?
Thanks,
Mathieu
> I recommend my fix.
>
> >
> > Also, there is no need to do the synchronize_sched with the marker mutex
> > held. call_rcu_sched takes care of making sure the previous quiescent
> > state is over before calling kfree. This means that when we return from
> > the register/unregister functions, there may still be markers "in
> > flight" using the old markers. Again, why would it be a problem ?
> >
> > Thanks,
> >
> > Mathieu
> >
> > P.S. : I'll send along the patches I am referring to. Ingo, those should
> > probably be merged if they are not in -tip already.
> >
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
prev parent reply other threads:[~2008-09-30 3:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-29 8:00 [PATCH] markers: fix unregister bug and reenter bug Lai Jiangshan
2008-09-29 8:27 ` Ingo Molnar
2008-09-29 15:03 ` Mathieu Desnoyers
2008-09-29 15:05 ` [PATCH] Markers : marker_synchronize_unregister() Mathieu Desnoyers
2008-09-30 1:47 ` Lai Jiangshan
[not found] ` <20081002235650.43ca075c.akpm@linux-foundation.org>
2008-10-03 15:52 ` [PATCH] Markers synchronize unregister static inline Mathieu Desnoyers
2008-10-03 17:31 ` Ingo Molnar
2008-09-29 15:06 ` [PATCH] RCU read sched Mathieu Desnoyers
2008-09-30 10:08 ` Ingo Molnar
2008-09-30 13:10 ` Paul E. McKenney
2008-09-30 13:10 ` Paul E. McKenney
2008-09-29 15:08 ` [PATCH] Markers use rcu_read_lock_sched() Mathieu Desnoyers
2008-09-30 10:13 ` Ingo Molnar
2008-09-29 15:09 ` [PATCH] Markers : probe example fix teardown Mathieu Desnoyers
2008-09-29 15:10 ` [PATCH] Markers : documentation " Mathieu Desnoyers
2008-09-29 15:11 ` [PATCH] sputrace : use marker_synchronize_unregister() Mathieu Desnoyers
2008-09-29 15:11 ` Mathieu Desnoyers
2008-09-29 15:13 ` Christoph Hellwig
2008-09-29 15:13 ` Christoph Hellwig
2008-09-30 0:28 ` Jeremy Kerr
2008-09-30 0:28 ` Jeremy Kerr
2008-09-30 9:55 ` Ingo Molnar
2008-09-30 9:55 ` Ingo Molnar
2008-09-30 11:22 ` [Cbe-oss-dev] " Jeremy Kerr
2008-09-30 11:22 ` Jeremy Kerr
2008-09-30 11:30 ` Ingo Molnar
2008-09-30 11:30 ` Ingo Molnar
2008-09-30 11:34 ` Jeremy Kerr
2008-09-30 11:34 ` Jeremy Kerr
2008-09-29 15:03 ` [PATCH] markers: fix unregister bug and reenter bug Mathieu Desnoyers
2008-09-30 1:40 ` Lai Jiangshan
2008-09-30 3:38 ` Mathieu Desnoyers [this message]
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=20080930033836.GA12733@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=akpm@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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.