On Mon, Feb 01, 2016 at 01:27:57PM +0100, Jiri Kosina wrote:
> On Fri, 29 Jan 2016, Josh Poimboeuf wrote:
>
> > Right, as you say it's basically a nop 99.99% of the time. But we still
> > need to do the "are any patches loaded" check, so we still need the call
> > into a livepatch function to d
On Fri, 29 Jan 2016, Josh Poimboeuf wrote:
> Right, as you say it's basically a nop 99.99% of the time. But we still
> need to do the "are any patches loaded" check, so we still need the call
> into a livepatch function to do that.
We might create a static key for that (some might call it
ove
On Fri, Jan 29, 2016 at 03:08:23PM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2016 13:47:15 -0600
> Josh Poimboeuf wrote:
>
>
> > > Although, I have to admit, if live kernel patching is configured in,
> > > it's not always needed to be called here, does it? With ftrace, the
> > > call has to
On Fri, 29 Jan 2016 13:47:15 -0600
Josh Poimboeuf wrote:
> > Although, I have to admit, if live kernel patching is configured in,
> > it's not always needed to be called here, does it? With ftrace, the
> > call has to be done when ftrace is configured in regardless if tracing
> > is used or not.
On Fri, Jan 29, 2016 at 02:29:50PM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2016 20:25:15 +0100 (CET)
> Miroslav Benes wrote:
>
> > It is possible to achieve the same goal even with the notifiers. They are
> > processed synchronously in complete_formation(). So we can put our klp
> > hook
On Fri, Jan 29, 2016 at 08:25:15PM +0100, Miroslav Benes wrote:
> On Fri, 29 Jan 2016, Josh Poimboeuf wrote:
>
> > On Fri, Jan 29, 2016 at 12:40:14PM -0500, Steven Rostedt wrote:
> > > [ Added Rusty, as he's still maintainer of the module code ]
> > >
> > > On Fri, 29 Jan 2016 11:30:10 -0600
> >
On Fri, 29 Jan 2016 20:25:15 +0100 (CET)
Miroslav Benes wrote:
> It is possible to achieve the same goal even with the notifiers. They are
> processed synchronously in complete_formation(). So we can put our klp
> hook after that, right? Or better, put it to load_module() after
> complete_form
On Fri, 29 Jan 2016, Josh Poimboeuf wrote:
> On Fri, Jan 29, 2016 at 12:40:14PM -0500, Steven Rostedt wrote:
> > [ Added Rusty, as he's still maintainer of the module code ]
> >
> > On Fri, 29 Jan 2016 11:30:10 -0600
> > Josh Poimboeuf wrote:
> >
> > > On Fri, Jan 29, 2016 at 05:30:46PM +0100,
On Fri, Jan 29, 2016 at 12:40:14PM -0500, Steven Rostedt wrote:
> [ Added Rusty, as he's still maintainer of the module code ]
>
> On Fri, 29 Jan 2016 11:30:10 -0600
> Josh Poimboeuf wrote:
>
> > On Fri, Jan 29, 2016 at 05:30:46PM +0100, Miroslav Benes wrote:
> > > Otherwise than that it looks g
[ Added Rusty, as he's still maintainer of the module code ]
On Fri, 29 Jan 2016 11:30:10 -0600
Josh Poimboeuf wrote:
> On Fri, Jan 29, 2016 at 05:30:46PM +0100, Miroslav Benes wrote:
> > Otherwise than that it looks good. I agree there are advantages to split
> > the notifiers. For example we
On Fri, Jan 29, 2016 at 05:30:46PM +0100, Miroslav Benes wrote:
> Otherwise than that it looks good. I agree there are advantages to split
> the notifiers. For example we can replace the coming one with the function
> call somewhere in load_module() to improve error handling if the patching
> fa
On Fri, 29 Jan 2016, Jessica Yu wrote:
> Detangle klp_module_notify() into two separate module notifiers
> klp_module_notify_{coming,going}() with the appropriate priorities,
> so that on module load, the ftrace module notifier will run *before*
> the livepatch coming module notifier but *after* t
Detangle klp_module_notify() into two separate module notifiers
klp_module_notify_{coming,going}() with the appropriate priorities,
so that on module load, the ftrace module notifier will run *before*
the livepatch coming module notifier but *after* the livepatch going
module modifier.
This fixes
13 matches
Mail list logo
