On Tue, Nov 18, 2014 at 01:47:46PM +0100, Petr Mladek wrote:
> On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
> > On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
> > > > It'd be mostly based on your refcounting code, including stack
> > > > checking (when a process sleeps,
On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
> On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
> > > It'd be mostly based on your refcounting code, including stack
> > > checking (when a process sleeps, counter gets set based on number of
> > > patched functions on the
On Tue, Nov 18, 2014 at 01:47:46PM +0100, Petr Mladek wrote:
On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
It'd be mostly based on your refcounting code, including stack
checking (when a process sleeps, counter gets
On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
It'd be mostly based on your refcounting code, including stack
checking (when a process sleeps, counter gets set based on number of
patched functions on the stack),
On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
> I see. I don't mind the implementation of how to check the execution path.
> I just considers that we need classify consistency requirements when
> checking the "patch" itself (maybe by manual at first).
>
> And since your
(2014/11/13 6:47), Vojtech Pavlik wrote:
> On Thu, Nov 13, 2014 at 02:33:24AM +0900, Masami Hiramatsu wrote:
>> Right. Consistency model is still same as kpatch. Btw, I think
>> we can just use the difference of consistency for classifying
>> the patches, since we have these classes, only limited
(2014/11/13 6:47), Vojtech Pavlik wrote:
On Thu, Nov 13, 2014 at 02:33:24AM +0900, Masami Hiramatsu wrote:
Right. Consistency model is still same as kpatch. Btw, I think
we can just use the difference of consistency for classifying
the patches, since we have these classes, only limited
On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
I see. I don't mind the implementation of how to check the execution path.
I just considers that we need classify consistency requirements when
checking the patch itself (maybe by manual at first).
And since your
On Thu, Nov 13, 2014 at 02:33:24AM +0900, Masami Hiramatsu wrote:
> Right. Consistency model is still same as kpatch. Btw, I think
> we can just use the difference of consistency for classifying
> the patches, since we have these classes, only limited combination
> is meaningful.
>
> >>
(2014/11/11 19:26), Vojtech Pavlik wrote:
> On Tue, Nov 11, 2014 at 10:24:03AM +0900, Masami Hiramatsu wrote:
>
>> Hmm, I doubt this can cover all. what I'm thinking is a combination of
>> LEAVE_KERNEL and SWITCH_KERNEL by using my refcounting and kGraft's
>> per-thread "new universe"
(2014/11/11 19:26), Vojtech Pavlik wrote:
On Tue, Nov 11, 2014 at 10:24:03AM +0900, Masami Hiramatsu wrote:
Hmm, I doubt this can cover all. what I'm thinking is a combination of
LEAVE_KERNEL and SWITCH_KERNEL by using my refcounting and kGraft's
per-thread new universe flagging(*). It
On Thu, Nov 13, 2014 at 02:33:24AM +0900, Masami Hiramatsu wrote:
Right. Consistency model is still same as kpatch. Btw, I think
we can just use the difference of consistency for classifying
the patches, since we have these classes, only limited combination
is meaningful.
LEAVE_FUNCTION
On Tue, Nov 11, 2014 at 10:05:05AM +0100, Vojtech Pavlik wrote:
> On Mon, Nov 10, 2014 at 11:09:03AM -0600, Josh Poimboeuf wrote:
> > > But there are a few (probably much less than 10%) cases like the locking
> > > one I used above, where SWITCH_THREAD just isn't going to cut it and for
> > >
On Tue, Nov 11, 2014 at 10:24:03AM +0900, Masami Hiramatsu wrote:
> Hmm, I doubt this can cover all. what I'm thinking is a combination of
> LEAVE_KERNEL and SWITCH_KERNEL by using my refcounting and kGraft's
> per-thread "new universe" flagging(*). It switches all threads but not
> change entire
On Mon, Nov 10, 2014 at 11:09:03AM -0600, Josh Poimboeuf wrote:
> > In fact LEAVE_KERNEL can be approximated by extending the patched
> > set as required to include functions which are not changed per se, but
> > are "contaminated" by propagation of semantic changes in the calling
> > convention,
On Mon, Nov 10, 2014 at 11:09:03AM -0600, Josh Poimboeuf wrote:
In fact LEAVE_KERNEL can be approximated by extending the patched
set as required to include functions which are not changed per se, but
are contaminated by propagation of semantic changes in the calling
convention, and/or
On Tue, Nov 11, 2014 at 10:24:03AM +0900, Masami Hiramatsu wrote:
Hmm, I doubt this can cover all. what I'm thinking is a combination of
LEAVE_KERNEL and SWITCH_KERNEL by using my refcounting and kGraft's
per-thread new universe flagging(*). It switches all threads but not
change entire
On Tue, Nov 11, 2014 at 10:05:05AM +0100, Vojtech Pavlik wrote:
On Mon, Nov 10, 2014 at 11:09:03AM -0600, Josh Poimboeuf wrote:
But there are a few (probably much less than 10%) cases like the locking
one I used above, where SWITCH_THREAD just isn't going to cut it and for
those I would
Hi,
(2014/11/08 6:27), Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
>
>>> LEAVE_FUNCTION
>>> LEAVE_PATCHED_SET
>>> LEAVE_KERNEL
>>>
>>> SWITCH_FUNCTION
>>> SWITCH_THREAD
>>> SWITCH_KERNEL
>>>
>>> Now with those definitions:
>>>
On Sat, Nov 08, 2014 at 09:07:54AM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
>
> > On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> > > On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> > >
> > > > >
On Sat, Nov 08, 2014 at 09:07:54AM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
Hi,
(2014/11/08 6:27), Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
SWITCH_FUNCTION
SWITCH_THREAD
SWITCH_KERNEL
Now with those definitions:
livepatch (null model), as
On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
> This patchset implements an ftrace-based mechanism and kernel interface for
> doing live patching of kernel and kernel module functions. It represents the
> greatest common functionality set between kpatch [1] and kGraft [2] and can
On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
This patchset implements an ftrace-based mechanism and kernel interface for
doing live patching of kernel and kernel module functions. It represents the
greatest common functionality set between kpatch [1] and kGraft [2] and can
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
> On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> > On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> >
> > > > LEAVE_FUNCTION
> > > > LEAVE_PATCHED_SET
> > > > LEAVE_KERNEL
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
>
> > > LEAVE_FUNCTION
> > > LEAVE_PATCHED_SET
> > > LEAVE_KERNEL
> > >
> > > SWITCH_FUNCTION
> > > SWITCH_THREAD
> > > SWITCH_KERNEL
> > >
> > > Now
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> > LEAVE_FUNCTION
> > LEAVE_PATCHED_SET
> > LEAVE_KERNEL
> >
> > SWITCH_FUNCTION
> > SWITCH_THREAD
> > SWITCH_KERNEL
> >
> > Now with those definitions:
> >
> > livepatch (null model), as is, is
On Fri, Nov 07, 2014 at 03:04:58PM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 07:11:53AM -0600, Josh Poimboeuf wrote:
>
> > 2. Add consistency model(s) (e.g. kpatch stop_machine, kGraft per-task
> >consistency, Masami's per task ref counting)
>
> I have given some thought to the
On Fri, Nov 07, 2014 at 07:11:53AM -0600, Josh Poimboeuf wrote:
> 2. Add consistency model(s) (e.g. kpatch stop_machine, kGraft per-task
>consistency, Masami's per task ref counting)
I have given some thought to the consistency models and how they differ
and how they potentially could be
On Thu, Nov 06, 2014 at 11:47:45PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > One reason is that there are currently at least two generators using
> > very different methods of generation (in addition to the option of doing
> > the patch
On Fri, Nov 07, 2014 at 01:48:45PM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> > >
> > > > On Thu, Nov
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> >
> > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > > > I don't think
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
>
> > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > > I don't think this specific example was generated.
> > >
> > > I also don't think
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this
On Fri, Nov 07, 2014 at 01:48:45PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at
On Thu, Nov 06, 2014 at 11:47:45PM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
One reason is that there are currently at least two generators using
very different methods of generation (in addition to the option of doing
the patch module
On Fri, Nov 07, 2014 at 07:11:53AM -0600, Josh Poimboeuf wrote:
2. Add consistency model(s) (e.g. kpatch stop_machine, kGraft per-task
consistency, Masami's per task ref counting)
I have given some thought to the consistency models and how they differ
and how they potentially could be
On Fri, Nov 07, 2014 at 03:04:58PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 07:11:53AM -0600, Josh Poimboeuf wrote:
2. Add consistency model(s) (e.g. kpatch stop_machine, kGraft per-task
consistency, Masami's per task ref counting)
I have given some thought to the
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
SWITCH_FUNCTION
SWITCH_THREAD
SWITCH_KERNEL
Now with those definitions:
livepatch (null model), as is, is LEAVE_FUNCTION and
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
SWITCH_FUNCTION
SWITCH_THREAD
SWITCH_KERNEL
Now with those definitions:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> One reason is that there are currently at least two generators using
> very different methods of generation (in addition to the option of doing
> the patch module by hand), and neither of them are currently in a state
> where they
On Thu, Nov 06, 2014 at 02:49:26PM -0500, Steven Rostedt wrote:
> I understand that there is two methods in doing this. Is it possible to
> create a "simple generator" that only does the simple case. Perhaps can
> detect non simple cases where it rejects the change and tells the user
> they need
On Thu, Nov 06, 2014 at 01:34:33PM -0600, Josh Poimboeuf wrote:
> I agree that we should also put kpatch-build (or some converged
> kpatch/kGraft-build tool) into the kernel tree, because of the tight
> interdependencies between it and the kernel. I think it would make
> development much easier.
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > I don't think this specific example was generated.
> >
> > I also don't think including the whole kpatch automation into the kernel
> > tree is a viable
On Thu, Nov 06, 2014 at 02:49:26PM -0500, Steven Rostedt wrote:
> On Thu, 6 Nov 2014 13:34:33 -0600
> Josh Poimboeuf wrote:
>
> > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > > > I don't think this
On Thu, 6 Nov 2014 13:34:33 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > > I don't think this specific example was generated.
>
> So there are two ways to use this live
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > I don't think this specific example was generated.
So there are two ways to use this live patching API: using a generated
module (e.g., using the kpatch-build
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> I don't think this specific example was generated.
>
> I also don't think including the whole kpatch automation into the kernel
> tree is a viable development model for it. (Same would apply for kGraft
> automation.)
Why? We
On Thu, Nov 06, 2014 at 10:44:46AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
> > An example patch module can be found here:
> > https://github.com/spartacus06/livepatch/blob/master/patch/patch.c
>
> Please include the generator for this
On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
> An example patch module can be found here:
> https://github.com/spartacus06/livepatch/blob/master/patch/patch.c
Please include the generator for this patch in the kernel tree.
Providing interfaces for out of tree modules (or
This patchset implements an ftrace-based mechanism and kernel interface for
doing live patching of kernel and kernel module functions. It represents the
greatest common functionality set between kpatch [1] and kGraft [2] and can
accept patches built using either method. This solution was
This patchset implements an ftrace-based mechanism and kernel interface for
doing live patching of kernel and kernel module functions. It represents the
greatest common functionality set between kpatch [1] and kGraft [2] and can
accept patches built using either method. This solution was
On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
An example patch module can be found here:
https://github.com/spartacus06/livepatch/blob/master/patch/patch.c
Please include the generator for this patch in the kernel tree.
Providing interfaces for out of tree modules (or
On Thu, Nov 06, 2014 at 10:44:46AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 08:39:06AM -0600, Seth Jennings wrote:
An example patch module can be found here:
https://github.com/spartacus06/livepatch/blob/master/patch/patch.c
Please include the generator for this patch in
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the whole kpatch automation into the kernel
tree is a viable development model for it. (Same would apply for kGraft
automation.)
Why? We (IMHO
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
So there are two ways to use this live patching API: using a generated
module (e.g., using the kpatch-build
On Thu, 6 Nov 2014 13:34:33 -0600
Josh Poimboeuf jpoim...@redhat.com wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
So there are two ways to use
On Thu, Nov 06, 2014 at 02:49:26PM -0500, Steven Rostedt wrote:
On Thu, 6 Nov 2014 13:34:33 -0600
Josh Poimboeuf jpoim...@redhat.com wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the whole kpatch automation into the kernel
tree is a viable development
On Thu, Nov 06, 2014 at 01:34:33PM -0600, Josh Poimboeuf wrote:
I agree that we should also put kpatch-build (or some converged
kpatch/kGraft-build tool) into the kernel tree, because of the tight
interdependencies between it and the kernel. I think it would make
development much easier.
On Thu, Nov 06, 2014 at 02:49:26PM -0500, Steven Rostedt wrote:
I understand that there is two methods in doing this. Is it possible to
create a simple generator that only does the simple case. Perhaps can
detect non simple cases where it rejects the change and tells the user
they need to
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
One reason is that there are currently at least two generators using
very different methods of generation (in addition to the option of doing
the patch module by hand), and neither of them are currently in a state
where they would
64 matches
Mail list logo
