From: Ingo Molnar <mingo@kernel.org>
To: Joel Fernandes <joel@joelfernandes.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Anders Roxell <anders.roxell@linaro.org>,
paulmck@kernel.org, "Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
David Miller <davem@davemloft.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip] kprobes: Lock rcu_read_lock() while searching kprobe
Date: Tue, 3 Dec 2019 08:13:29 +0100 [thread overview]
Message-ID: <20191203071329.GC115767@gmail.com> (raw)
In-Reply-To: <20191202210854.GD17234@google.com>
* Joel Fernandes <joel@joelfernandes.org> wrote:
> On Mon, Dec 02, 2019 at 04:32:13PM +0900, Masami Hiramatsu wrote:
> > Anders reported that the lockdep warns that suspicious
> > RCU list usage in register_kprobe() (detected by
> > CONFIG_PROVE_RCU_LIST.) This is because get_kprobe()
> > access kprobe_table[] by hlist_for_each_entry_rcu()
> > without rcu_read_lock.
> >
> > If we call get_kprobe() from the breakpoint handler context,
> > it is run with preempt disabled, so this is not a problem.
> > But in other cases, instead of rcu_read_lock(), we locks
> > kprobe_mutex so that the kprobe_table[] is not updated.
> > So, current code is safe, but still not good from the view
> > point of RCU.
> >
> > Let's lock the rcu_read_lock() around get_kprobe() and
> > ensure kprobe_mutex is locked at those points.
> >
> > Note that we can safely unlock rcu_read_lock() soon after
> > accessing the list, because we are sure the found kprobe has
> > never gone before unlocking kprobe_mutex. Unless locking
> > kprobe_mutex, caller must hold rcu_read_lock() until it
> > finished operations on that kprobe.
> >
> > Reported-by: Anders Roxell <anders.roxell@linaro.org>
> > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
>
> Instead of this, can you not just pass the lockdep_is_held() expression as
> the last argument to list_for_each_entry_rcu() to silence the warning? Then
> it will be a simpler patch.
Come on, we do not silence warnings!
If it's safely inside the lock then why not change it from
hlist_for_each_entry_rcu() to hlist_for_each_entry()?
I do think that 'lockdep flag' inside hlist_for_each_entry_rcu():
/**
* hlist_for_each_entry_rcu - iterate over rcu list of given type
* @pos: the type * to use as a loop cursor.
* @head: the head for your list.
* @member: the name of the hlist_node within the struct.
* @cond: optional lockdep expression if called from non-RCU protection.
*
* This list-traversal primitive may safely run concurrently with
* the _rcu list-mutation primitives such as hlist_add_head_rcu()
* as long as the traversal is guarded by rcu_read_lock().
*/
#define hlist_for_each_entry_rcu(pos, head, member, cond...) \
is actively harmful. Why is it there?
Thanks,
Ingo
next prev parent reply other threads:[~2019-12-03 7:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 7:32 [PATCH -tip] kprobes: Lock rcu_read_lock() while searching kprobe Masami Hiramatsu
2019-12-02 15:17 ` Anders Roxell
2019-12-02 21:08 ` Joel Fernandes
2019-12-02 22:34 ` Masami Hiramatsu
2019-12-02 23:35 ` Joel Fernandes
2019-12-03 6:02 ` Masami Hiramatsu
2019-12-03 7:13 ` Ingo Molnar [this message]
2019-12-03 17:57 ` Paul E. McKenney
2019-12-04 10:05 ` Ingo Molnar
2019-12-04 16:12 ` Paul E. McKenney
2019-12-05 4:19 ` Masami Hiramatsu
2019-12-06 1:11 ` Joel Fernandes
2019-12-06 3:11 ` Paul E. McKenney
2019-12-08 0:08 ` Joel Fernandes
2019-12-09 3:39 ` Paul E. McKenney
2019-12-17 14:59 ` Masami Hiramatsu
2019-12-17 18:07 ` Joel Fernandes
2019-12-04 4:09 ` Joel Fernandes
2019-12-04 4:20 ` 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=20191203071329.GC115767@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=anders.roxell@linaro.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=paulmck@kernel.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.