public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: <linux-kernel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Subject: Re: [PATCH] kprobes: Print an error if probe is rejected
Date: Thu, 10 Jun 2021 19:16:43 +0900	[thread overview]
Message-ID: <20210610191643.d24e7d56d102567070fe8386@kernel.org> (raw)
In-Reply-To: <20210610085617.1590138-1-naveen.n.rao@linux.vnet.ibm.com>

Hi Naveen,

On Thu, 10 Jun 2021 14:26:17 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:

> When probing at different locations in the kernel, it is not always
> evident if the location can be probed or not. As an example:
> 
>     $ perf probe __radix__flush_tlb_range:35
>     Failed to write event: Invalid argument
>       Error: Failed to add events.
> 
> The probed line above is:
>      35         if (!mmu_has_feature(MMU_FTR_GTSE) && type == FLUSH_TYPE_GLOBAL) {
> 
> This ends up trying to probe on BUILD_BUG_ON(), which is rejected.
> However, the user receives no indication at all as to why the probe
> failed. Print an error in such cases so that it is clear that the probe
> was rejected.

Hmm, Nack for this way, but I understand that is a problem.
If you got the error in perf probe, which uses ftrace dynamic-event interface.
In that case, the errors should not be output in the dmesg, but are reported
via error_log in tracefs.
And kprobes itself should return different error code to the caller, instead
of printing error in dmesg. See below.

[...]
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1542,8 +1542,10 @@ static int check_kprobe_address_safe(struct kprobe *p,
>  	int ret;
>  
>  	ret = arch_check_ftrace_location(p);
> -	if (ret)
> +	if (ret) {
> +		pr_err("kprobes: can't probe at the provided ftrace location\n");
>  		return ret;

This must be -EBUSY. (or arch depend return value)

> +	}
>  	jump_label_lock();
>  	preempt_disable();
>  
> @@ -1552,6 +1554,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
>  	    within_kprobe_blacklist((unsigned long) p->addr) ||
>  	    jump_label_text_reserved(p->addr, p->addr) ||
>  	    find_bug((unsigned long)p->addr)) {
> +		pr_err("kprobes: can't probe at address in reject list\n");
>  		ret = -EINVAL;

This maybe -EACCESS.

>  		goto out;
>  	}
> @@ -1976,8 +1979,10 @@ int register_kretprobe(struct kretprobe *rp)
>  	void *addr;
>  
>  	ret = kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset);
> -	if (ret)
> +	if (ret) {
> +		pr_err("kretprobes: can't probe at address outside function entry\n");
>  		return ret;

return -ERANGE.

> +	}
>  
>  	/* If only rp->kp.addr is specified, check reregistering kprobes */
>  	if (rp->kp.addr && warn_kprobe_rereg(&rp->kp))
> @@ -1989,8 +1994,10 @@ int register_kretprobe(struct kretprobe *rp)
>  			return PTR_ERR(addr);
>  
>  		for (i = 0; kretprobe_blacklist[i].name != NULL; i++) {
> -			if (kretprobe_blacklist[i].addr == addr)
> +			if (kretprobe_blacklist[i].addr == addr) {
> +				pr_err("kretprobes: can't probe at address in reject list\n");
>  				return -EINVAL;

return -EACCESS too.

Thank you,

> +			}
>  		}
>  	}
>  
> 
> base-commit: 2e38eb04c95e5546b71bb86ee699a891c7d212b5
> -- 
> 2.31.1
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2021-06-10 10:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10  8:56 [PATCH] kprobes: Print an error if probe is rejected Naveen N. Rao
2021-06-10 10:16 ` Masami Hiramatsu [this message]
2021-06-10 17:33   ` Steven Rostedt
2021-06-11  1:50     ` Masami Hiramatsu
2021-06-11 13:55   ` Naveen N. Rao
2021-06-11 19:40     ` Steven Rostedt
2021-06-14 15:30       ` Naveen N. Rao
2021-06-18 16:15         ` Masami Hiramatsu
2021-06-21  9:36           ` Naveen N. Rao
2021-06-21 12:54             ` Masami Hiramatsu
2021-06-12  1:13     ` Masami Hiramatsu
2021-06-14 15:37       ` Naveen N. Rao
2021-06-15  5:42         ` Masami Hiramatsu

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=20210610191643.d24e7d56d102567070fe8386@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naveen.n.rao@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox