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, coun
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 classi
(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 c
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_F
(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(*).
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
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,
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:
> > >
> > > > > LEAVE
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 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
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_F
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 c
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 unif
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 mo
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 0
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 t
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 inclu
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 wo
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 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 develo
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 spe
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 pa
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 t
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 (IMH
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
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 generato
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 discusse
32 matches
Mail list logo
