Commit-ID: 12310e3437554328bcd75186cf331bc712cb30b2
Gitweb: https://git.kernel.org/tip/12310e3437554328bcd75186cf331bc712cb30b2
Author: Jessica Yu
AuthorDate: Wed, 10 Jan 2018 00:51:23 +0100
Committer: Ingo Molnar
CommitDate: Fri, 16 Feb 2018 09:12:52 +0100
kprobes: Propagate error
Commit-ID: 384f1d86a8890fcf8118add0b6a0785ee35f5a65
Gitweb: https://git.kernel.org/tip/384f1d86a8890fcf8118add0b6a0785ee35f5a65
Author: Jessica Yu
AuthorDate: Wed, 10 Jan 2018 00:51:23 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Feb 2018 18:20:00 +0100
kprobes: Propagate error
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previously, this has lead to
confusing situations where register_kprobe() would return 0 indicating
success, b
On Mon, 8 Jan 2018 03:47:49 +0100
Jessica Yu wrote:
> Improve error handling when arming ftrace-based kprobes. Specifically, if
> we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
> should report an error instead of success. Previously, this has lead to
> confusing situatio
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previously, this has lead to
confusing situations where register_kprobe() would return 0 indicating
success, b
On Wed, 3 Jan 2018 22:00:00 +0100
Jessica Yu wrote:
> +++ Steven Rostedt [03/01/18 09:33 -0500]:
> >On Wed, 3 Jan 2018 02:40:47 +0100
> >Jessica Yu wrote:
> >
> >> Improve error handling when arming ftrace-based kprobes. Specifically, if
> >> we fail to arm a ftrace-based kprobe, register_kprob
+++ Steven Rostedt [03/01/18 09:33 -0500]:
On Wed, 3 Jan 2018 02:40:47 +0100
Jessica Yu wrote:
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previousl
On Wed, 3 Jan 2018 02:40:47 +0100
Jessica Yu wrote:
> Improve error handling when arming ftrace-based kprobes. Specifically, if
> we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
> should report an error instead of success. Previously, this has lead to
> confusing situatio
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previously, this has lead to
confusing situations where register_kprobe() would return 0 indicating
success, b
+++ Masami Hiramatsu [09/11/17 09:35 +0900]:
On Tue, 7 Nov 2017 18:14:56 +0100
Jessica Yu wrote:
+++ Steven Rostedt [03/11/17 10:03 -0400]:
>On Thu, 2 Nov 2017 17:33:33 +0100
>Jessica Yu wrote:
>
>> Improve error handling when arming ftrace-based kprobes. Specifically, if
>> we fail to arm a
On Tue, 7 Nov 2017 18:14:56 +0100
Jessica Yu wrote:
> +++ Steven Rostedt [03/11/17 10:03 -0400]:
> >On Thu, 2 Nov 2017 17:33:33 +0100
> >Jessica Yu wrote:
> >
> >> Improve error handling when arming ftrace-based kprobes. Specifically, if
> >> we fail to arm a ftrace-based kprobe, register_kprob
+++ Steven Rostedt [03/11/17 10:03 -0400]:
On Thu, 2 Nov 2017 17:33:33 +0100
Jessica Yu wrote:
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previousl
Hi Jessica,
Since this is under discussion about ftrace part, I just comment another one.
On Thu, 2 Nov 2017 17:33:33 +0100
Jessica Yu wrote:
[...]
> @@ -1362,9 +1372,14 @@ static int register_aggr_kprobe(struct kprobe *orig_p,
> struct kprobe *p)
>
> if (ret == 0 && kprobe_disabled(a
On Fri, 3 Nov 2017 13:33:12 -0400
Steven Rostedt wrote:
> On Fri, 3 Nov 2017 09:53:37 -0500
> Josh Poimboeuf wrote:
>
> > > > -static void arm_kprobe_ftrace(struct kprobe *p)
> > > > +static int arm_kprobe_ftrace(struct kprobe *p)
> > > > {
> > > > - int ret;
> > > > + int ret = 0;
On Fri, 3 Nov 2017 09:53:37 -0500
Josh Poimboeuf wrote:
> > > -static void arm_kprobe_ftrace(struct kprobe *p)
> > > +static int arm_kprobe_ftrace(struct kprobe *p)
> > > {
> > > - int ret;
> > > + int ret = 0;
> > >
> > > ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
> > >
On Fri, Nov 03, 2017 at 10:03:17AM -0400, Steven Rostedt wrote:
> On Thu, 2 Nov 2017 17:33:33 +0100
> Jessica Yu wrote:
>
> > Improve error handling when arming ftrace-based kprobes. Specifically, if
> > we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
> > should report an
On Thu, 2 Nov 2017 17:33:33 +0100
Jessica Yu wrote:
> Improve error handling when arming ftrace-based kprobes. Specifically, if
> we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
> should report an error instead of success. Previously, this has lead to
> confusing situatio
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previously, this has lead to
confusing situations where register_kprobe() would return 0 indicating
success, b
+++ Masami Hiramatsu [05/10/17 06:23 +]:
Hi Jessica,
On Wed, 4 Oct 2017 21:14:13 +0200
Jessica Yu wrote:
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of suc
Hi Jessica,
On Wed, 4 Oct 2017 21:14:13 +0200
Jessica Yu wrote:
> Improve error handling when arming ftrace-based kprobes. Specifically, if
> we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
> should report an error instead of success. Previously, this has lead to
> confu
Improve error handling when arming ftrace-based kprobes. Specifically, if
we fail to arm a ftrace-based kprobe, register_kprobe()/enable_kprobe()
should report an error instead of success. Previously, this has lead to
confusing situations where register_kprobe() would return 0 indicating
success, b
(2015/02/27 1:13), Petr Mladek wrote:
> arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
> flag and LifePatching.
>
> registry_kprobe() and registry_aggr_kprobe() do not mind about the error
> because the kprobe gets disabled and they keep it registered.
>
> But enable
arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching.
registry_kprobe() and registry_aggr_kprobe() do not mind about the error
because the kprobe gets disabled and they keep it registered.
But enable_kprobe() should propagate the error because its tas
23 matches
Mail list logo
