Re: [PATCH 4/6] kprobes/ftrace: Use ftrace_location() when [dis]arming probes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patch 4/5 is from arm64’s KPROBES_ON_FTRACE,  I think which is needed by
all RISC with both KPROBES_ON_FTRACE and -fpatchable-function-entry.

But since V7, no further patches are released, what protocol should I follow if
I need these two patches?

> On Mar 26, 2021, at 3:44 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> On Sat, 13 Mar 2021 14:41:47 +0800
> Huang Pei <huangpei@xxxxxxxxxxx> wrote:
> 
>> From: Jisheng Zhang <Jisheng.Zhang@xxxxxxxxxxxxx>
>> 
> 
> Looks like this was sent before, but was missing the proper authorship
> (which is not Jisheng).
> 
>   https://lore.kernel.org/linux-arm-kernel/20191225173219.4f9db436@xhacker.debian/
> 
> -- Steve
> 
> 
>> Ftrace location could include more than a single instruction in case
>> of some architectures (powerpc64, for now). In this case, kprobe is
>> permitted on any of those instructions, and uses ftrace infrastructure
>> for functioning.
>> 
>> However, [dis]arm_kprobe_ftrace() uses the kprobe address when setting
>> up ftrace filter IP. This won't work if the address points to any
>> instruction apart from the one that has a branch to _mcount(). To
>> resolve this, have [dis]arm_kprobe_ftrace() use ftrace_function() to
>> identify the filter IP.
>> 
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@xxxxxxxxxxxxxxxxxx>
>> Acked-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
>> ---
>> kernel/kprobes.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>> 
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index 41fdbb7953c6..66ee28b071c2 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
>> @@ -1045,9 +1045,10 @@ static int prepare_kprobe(struct kprobe *p)
>> static int __arm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
>> 			       int *cnt)
>> {
>> +	unsigned long ftrace_ip = ftrace_location((unsigned long)p->addr);
>> 	int ret = 0;
>> 
>> -	ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 0, 0);
>> +	ret = ftrace_set_filter_ip(ops, ftrace_ip, 0, 0);
>> 	if (ret) {
>> 		pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
>> 			 p->addr, ret);
>> @@ -1070,7 +1071,7 @@ static int __arm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
>> 	 * At this point, sinec ops is not registered, we should be sefe from
>> 	 * registering empty filter.
>> 	 */
>> -	ftrace_set_filter_ip(ops, (unsigned long)p->addr, 1, 0);
>> +	ftrace_set_filter_ip(ops, ftrace_ip, 1, 0);
>> 	return ret;
>> }
>> 
>> @@ -1087,6 +1088,7 @@ static int arm_kprobe_ftrace(struct kprobe *p)
>> static int __disarm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
>> 				  int *cnt)
>> {
>> +	unsigned long ftrace_ip = ftrace_location((unsigned long)p->addr);
>> 	int ret = 0;
>> 
>> 	if (*cnt == 1) {
>> @@ -1097,7 +1099,7 @@ static int __disarm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
>> 
>> 	(*cnt)--;
>> 
>> -	ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 1, 0);
>> +	ret = ftrace_set_filter_ip(ops, ftrace_ip, 1, 0);
>> 	WARN_ONCE(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
>> 		  p->addr, ret);
>> 	return ret;

Huang Pei
huangpei@xxxxxxxxxxx






[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux