On Wed, 23 Jul 2014 19:05:52 +0200
Oleg Nesterov wrote:
> > kprobe ftrace_ops are allocated which sets the FTRACE_OPS_FL_DYNAMIC
> > flag. You'll see that flag checked in update_ftrace_function(), and if
> > it is set, it forces the ftrace_ops_list_func() to be used.
>
> No? __register_ftrace_f
On 07/23, Steven Rostedt wrote:
>
> On Wed, 23 Jul 2014 14:08:05 +0200
> Oleg Nesterov wrote:
>
> > With this stupid patch
> >
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -4464,6 +4464,7 @@ __ftrace_ops_list_func(unsigned long ip, unsigned
> > long parent_ip
On Wed, 23 Jul 2014 14:08:05 +0200
Oleg Nesterov wrote:
> On 07/22, Steven Rostedt wrote:
> >
> > On Tue, 22 Jul 2014 18:47:07 +0200
> > Oleg Nesterov wrote:
> >
> > > On 07/03, Steven Rostedt wrote:
> > >
> > > > The way the function callback mechanism works in ftrace is that if
> > > > there'
On 07/22, Steven Rostedt wrote:
>
> On Tue, 22 Jul 2014 18:47:07 +0200
> Oleg Nesterov wrote:
>
> > On 07/03, Steven Rostedt wrote:
> >
> > > The way the function callback mechanism works in ftrace is that if there's
> > > only one function callback registered, it will set the mcount/fentry
> > >
On Tue, 22 Jul 2014 18:47:07 +0200
Oleg Nesterov wrote:
> On 07/03, Steven Rostedt wrote:
> >
> > [ NOT READY FOR INCLUSION! ]
> >
> > Note, this is based off of my remove ftrace_start/stop() patch set.
>
> So I simply pulled your tree. I can't really comment these changes simply
> because I do
On 07/03, Steven Rostedt wrote:
>
> [ NOT READY FOR INCLUSION! ]
>
> Note, this is based off of my remove ftrace_start/stop() patch set.
So I simply pulled your tree. I can't really comment these changes simply
because I do not understand this code. But I am hunting for RHEL bug in
(probably) this
(2014/07/14 23:18), Namhyung Kim wrote:
> 2014-07-14 (월), 17:18 +0900, Masami Hiramatsu:
>> (2014/07/14 16:16), Namhyung Kim wrote:
>>> Hi Masami,
>>>
>>> On Mon, 14 Jul 2014 10:35:21 +0900, Masami Hiramatsu wrote:
(2014/07/11 23:29), Josh Poimboeuf wrote:
> Here's the same stack trace wit
2014-07-14 (월), 17:18 +0900, Masami Hiramatsu:
> (2014/07/14 16:16), Namhyung Kim wrote:
> > Hi Masami,
> >
> > On Mon, 14 Jul 2014 10:35:21 +0900, Masami Hiramatsu wrote:
> >> (2014/07/11 23:29), Josh Poimboeuf wrote:
> >>> Here's the same stack trace with this patch:
> >>>
> >>> [ 1314.612287]
(2014/07/14 16:16), Namhyung Kim wrote:
> Hi Masami,
>
> On Mon, 14 Jul 2014 10:35:21 +0900, Masami Hiramatsu wrote:
>> (2014/07/11 23:29), Josh Poimboeuf wrote:
>> [...]
>>>
>>> >From 951d2aec17885a62905df6b910dc705d99c63993 Mon Sep 17 00:00:00 2001
>>> From: Josh Poimboeuf
>>> Date: Fri, 11 Jul
Hi Masami,
On Mon, 14 Jul 2014 10:35:21 +0900, Masami Hiramatsu wrote:
> (2014/07/11 23:29), Josh Poimboeuf wrote:
> [...]
>>
>>>From 951d2aec17885a62905df6b910dc705d99c63993 Mon Sep 17 00:00:00 2001
>> From: Josh Poimboeuf
>> Date: Fri, 11 Jul 2014 08:58:33 -0500
>> Subject: [PATCH] x86/dumpsta
(2014/07/11 23:29), Josh Poimboeuf wrote:
[...]
>
>>From 951d2aec17885a62905df6b910dc705d99c63993 Mon Sep 17 00:00:00 2001
> From: Josh Poimboeuf
> Date: Fri, 11 Jul 2014 08:58:33 -0500
> Subject: [PATCH] x86/dumpstack: fix stack traces for generated code
>
> If a function in the stack trace is
On Fri, Jul 11, 2014 at 03:24:28PM +0200, Jiri Kosina wrote:
> On Fri, 11 Jul 2014, Masami Hiramatsu wrote:
>
> > >> I did some testing with kpatch and I found one minor issue. The
> > >> dynamically
> > >> allocated trampoline seems to confuse dump_stack() somewhat.
> > >>
> > >> I added a dump
On Fri, 11 Jul 2014, Masami Hiramatsu wrote:
> >> I did some testing with kpatch and I found one minor issue. The
> >> dynamically
> >> allocated trampoline seems to confuse dump_stack() somewhat.
> >>
> >> I added a dump_stack() call in my ftrace_ops callback function
> >> (kpatch_ftrace_handle
(2014/07/11 6:44), Jiri Kosina wrote:
> On Thu, 10 Jul 2014, Josh Poimboeuf wrote:
>
>> I did some testing with kpatch and I found one minor issue. The dynamically
>> allocated trampoline seems to confuse dump_stack() somewhat.
>>
>> I added a dump_stack() call in my ftrace_ops callback function
On Thu, Jul 10, 2014 at 11:44:43PM +0200, Jiri Kosina wrote:
> On Thu, 10 Jul 2014, Josh Poimboeuf wrote:
>
> > I did some testing with kpatch and I found one minor issue. The dynamically
> > allocated trampoline seems to confuse dump_stack() somewhat.
> >
> > I added a dump_stack() call in my f
On Thu, 10 Jul 2014, Josh Poimboeuf wrote:
> I did some testing with kpatch and I found one minor issue. The dynamically
> allocated trampoline seems to confuse dump_stack() somewhat.
>
> I added a dump_stack() call in my ftrace_ops callback function
> (kpatch_ftrace_handler) which had a filter
On Thu, Jul 03, 2014 at 04:07:50PM -0400, Steven Rostedt wrote:
> [ NOT READY FOR INCLUSION! ]
>
> Note, this is based off of my remove ftrace_start/stop() patch set.
>
> I've been wanting to do this for years, and just never gotten around to it.
> But with all this talk of kpatch and kgraft live
On Mon, 7 Jul 2014 15:22:27 +0200 (CEST)
Jiri Kosina wrote:
> On Fri, 4 Jul 2014, Steven Rostedt wrote:
>
> > Well, I guess the answer to that is what do you consider the trampoline?
> > I'm currently considering it to be the assembly code that the
> > mcount/fentry call jumps to. We only have
On Thu, 3 Jul 2014, Steven Rostedt wrote:
> [ NOT READY FOR INCLUSION! ]
>
> Note, this is based off of my remove ftrace_start/stop() patch set.
>
> I've been wanting to do this for years, and just never gotten around to it.
> But with all this talk of kpatch and kgraft live kernel patching usin
On Fri, 4 Jul 2014, Steven Rostedt wrote:
> Well, I guess the answer to that is what do you consider the trampoline?
> I'm currently considering it to be the assembly code that the
> mcount/fentry call jumps to. We only have two trampolines (three if you
> count the function graph code that wil
On Fri, 04 Jul 2014 22:20:12 +0900
Masami Hiramatsu wrote:
> (2014/07/04 5:07), Steven Rostedt wrote:
> > [ NOT READY FOR INCLUSION! ]
> >
> > Note, this is based off of my remove ftrace_start/stop() patch set.
> >
> > I've been wanting to do this for years, and just never gotten around to it.
(2014/07/04 5:07), Steven Rostedt wrote:
> [ NOT READY FOR INCLUSION! ]
>
> Note, this is based off of my remove ftrace_start/stop() patch set.
>
> I've been wanting to do this for years, and just never gotten around to it.
> But with all this talk of kpatch and kgraft live kernel patching using
On Thu, 03 Jul 2014 16:07:50 -0400
Steven Rostedt wrote:
> [ NOT READY FOR INCLUSION! ]
One more thing to note. This will not go in before 3.18 (and depending
on issues, maybe later than that).
-- Steve
>
> Note, this is based off of my remove ftrace_start/stop() patch set.
>
> I've been wan
[ NOT READY FOR INCLUSION! ]
Note, this is based off of my remove ftrace_start/stop() patch set.
I've been wanting to do this for years, and just never gotten around to it.
But with all this talk of kpatch and kgraft live kernel patching using
the ftrace infrastructure, it seems like a good time
24 matches
Mail list logo
