All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangshaobo (bobo)" <bobo.shaobowang@huawei.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	<naveen.n.rao@linux.ibm.com>, <anil.s.keshavamurthy@intel.com>,
	<davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
	<huawei.libin@huawei.com>, <cj.chengjian@huawei.com>
Subject: Re: [PATCH] kretprobe: avoid re-registration of the same kretprobe earlier
Date: Mon, 21 Dec 2020 21:31:42 +0800	[thread overview]
Message-ID: <c584f7e2-1d95-4f6a-7e36-4ff2d610bc78@huawei.com> (raw)
In-Reply-To: <20201215123119.35258dd5006942be247600db@kernel.org>

Hi steven, Masami,
We have encountered a problem, when we attempted to use steven's suggestion as following,

>>> If you call this here, you must make sure kprobe_addr() is called on rp->kp.
>>> But if kretprobe_blacklist_size == 0, kprobe_addr() is not called before
>>> this check. So it should be in between kprobe_on_func_entry() and
>>> kretprobe_blacklist_size check, like this
>>>
>>> 	if (!kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset))
>>> 		return -EINVAL;
>>>
>>> 	addr = kprobe_addr(&rp->kp);
>>> 	if (IS_ERR(addr))
>>> 		return PTR_ERR(addr);
>>> 	rp->kp.addr = addr;

//there exists no-atomic operation risk, we should not modify any rp->kp's information, not all arch ensure atomic operation here.

>>>
>>> 	ret = check_kprobe_rereg(&rp->kp);
>>> 	if (WARN_ON(ret))
>>> 		return ret;
>>>
>>>           if (kretprobe_blacklist_size) {
>>> 		for (i = 0; > > +	ret = check_kprobe_rereg(&rp->kp);

it returns failure from register_kprobe() end called by register_kretprobe() when
we registered a kretprobe through .symbol_name at first time(through .addr is OK),
kprobe_addr() called at the begaining of register_kprobe() will recheck and
failed at following place because at this time we symbol_name is not NULL and addr is also.

   static kprobe_opcode_t *_kprobe_addr(const char *symbol_name,
                          unsigned int offset)
    {
          if ((symbol_name && addr) || (!symbol_name && !addr))  //we failed here


So we attempted to move this sentence rp->kp.addr = addr to __get_valid_kprobe() like this to
avoid explict usage of rp->kp.addr = addr in register_kretprobe().

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index dd5821f753e6..ea014779edfe 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1502,10 +1502,15 @@ static kprobe_opcode_t *kprobe_addr(struct kprobe *p)
  static struct kprobe *__get_valid_kprobe(struct kprobe *p)
  {
         struct kprobe *ap, *list_p;
+       void *addr;

         lockdep_assert_held(&kprobe_mutex);

-       ap = get_kprobe(p->addr);
+       addr = kprobe_addr(p);
+       if (IS_ERR(addr))
+               return NULL;
+
+       ap = get_kprobe(addr);
         if (unlikely(!ap))
                 return NULL;

But it also failed when we second time attempted to register a same kretprobe, it is also
becasue symbol_name and addr is not NULL when we used __get_valid_kprobe().

So it seems has no idea expect for modifying _kprobe_addr() like following this, the reason is that
the patch 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()")
has telled us we'd better use symbol name to register but not address anymore.

-static kprobe_opcode_t *_kprobe_addr(kprobe_opcode_t *addr,
-                       const char *symbol_name, unsigned int offset)
+static kprobe_opcode_t *_kprobe_addr(const char *symbol_name,
+                       unsigned int offset)
  {
-       if ((symbol_name && addr) || (!symbol_name && !addr))
+       kprobe_opcode_t *addr;
+       if (!symbol_name)
                 goto invalid;

For us, this modification has not caused a big impact on other modules, only expects a little
influence on bpf from calling trace_kprobe_on_func_entry(), it can not use addr to fill in
rp.kp in struct trace_event_call anymore.

So i want to know your views, and i will resend this patch soon.

thanks,
Wang Shaobo

>>>
>

  parent reply	other threads:[~2020-12-21 13:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 11:57 [PATCH] kretprobe: avoid re-registration of the same kretprobe earlier Wang ShaoBo
2020-11-30 21:18 ` Steven Rostedt
2020-12-01 23:32   ` Masami Hiramatsu
2020-12-02  1:23     ` Wangshaobo (bobo)
2020-12-02  1:27       ` Steven Rostedt
2020-12-14 16:36       ` Steven Rostedt
2020-12-15  3:31       ` Masami Hiramatsu
2020-12-15  8:39         ` Wangshaobo (bobo)
2020-12-21 13:31         ` Wangshaobo (bobo) [this message]
2020-12-22 11:03           ` Masami Hiramatsu
2021-01-13 22:48             ` Steven Rostedt
2021-01-14  0:25               ` Masami Hiramatsu
2021-01-14  1:06                 ` Wangshaobo (bobo)
2021-01-29  3:37             ` Wangshaobo (bobo)

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=c584f7e2-1d95-4f6a-7e36-4ff2d610bc78@huawei.com \
    --to=bobo.shaobowang@huawei.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=cj.chengjian@huawei.com \
    --cc=davem@davemloft.net \
    --cc=huawei.libin@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=naveen.n.rao@linux.ibm.com \
    --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.