+++ Miroslav Benes [06/04/16 10:43 +0200]:
On Wed, 6 Apr 2016, Miroslav Benes wrote:
Anyway I see there are some new comments on github. I'll look at those.
But I'd prefer to discuss all the relevant things (that is kpatch
unspecific) here. It would make it easier.
And you do (after seeing
+++ Miroslav Benes [06/04/16 10:43 +0200]:
On Wed, 6 Apr 2016, Miroslav Benes wrote:
Anyway I see there are some new comments on github. I'll look at those.
But I'd prefer to discuss all the relevant things (that is kpatch
unspecific) here. It would make it easier.
And you do (after seeing
+++ Jessica Yu [05/04/16 15:19 -0400]:
+++ Miroslav Benes [05/04/16 15:07 +0200]:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the
+++ Jessica Yu [05/04/16 15:19 -0400]:
+++ Miroslav Benes [05/04/16 15:07 +0200]:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the
On Wed, 6 Apr 2016, Chris J Arges wrote:
> On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote:
> > On Wed, 6 Apr 2016, Chris J Arges wrote:
> >
> > > I think this approach needs more thought and my code has bug(s).
> >
> > And indeed there is...
> >
> > long
On Wed, 6 Apr 2016, Chris J Arges wrote:
> On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote:
> > On Wed, 6 Apr 2016, Chris J Arges wrote:
> >
> > > I think this approach needs more thought and my code has bug(s).
> >
> > And indeed there is...
> >
> > long
On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Chris J Arges wrote:
>
> > I think this approach needs more thought and my code has bug(s).
>
> And indeed there is...
>
> long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned
> long
On Wed, Apr 06, 2016 at 02:09:01PM +0200, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Chris J Arges wrote:
>
> > I think this approach needs more thought and my code has bug(s).
>
> And indeed there is...
>
> long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned
> long
On Wed, 6 Apr 2016, Chris J Arges wrote:
> I think this approach needs more thought and my code has bug(s).
And indeed there is...
long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned
long arg) = NULL;
Use a different name than __kvm_arch_vm_ioctl and (ideally) make it
On Wed, 6 Apr 2016, Chris J Arges wrote:
> I think this approach needs more thought and my code has bug(s).
And indeed there is...
long (*__kvm_arch_vm_ioctl)(struct file *filp, unsigned long ioctl, unsigned
long arg) = NULL;
Use a different name than __kvm_arch_vm_ioctl and (ideally) make it
On Wed, Apr 06, 2016 at 11:09:04AM +0200, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Chris J Arges wrote:
>
> > On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> > >
> > > > So I think this doesn't fix the problem. Dynamic
On Wed, Apr 06, 2016 at 11:09:04AM +0200, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Chris J Arges wrote:
>
> > On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> > > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> > >
> > > > So I think this doesn't fix the problem. Dynamic
On Wed, 6 Apr 2016, Chris J Arges wrote:
> On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> >
> > > So I think this doesn't fix the problem. Dynamic relocations are
> > > applied to the "patch module", whereas the above code deals
On Wed, 6 Apr 2016, Chris J Arges wrote:
> On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> >
> > > So I think this doesn't fix the problem. Dynamic relocations are
> > > applied to the "patch module", whereas the above code deals
On Wed, 6 Apr 2016, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Miroslav Benes wrote:
>
> > Anyway I see there are some new comments on github. I'll look at those.
> > But I'd prefer to discuss all the relevant things (that is kpatch
> > unspecific) here. It would make it easier.
>
> And you
On Wed, 6 Apr 2016, Miroslav Benes wrote:
> On Wed, 6 Apr 2016, Miroslav Benes wrote:
>
> > Anyway I see there are some new comments on github. I'll look at those.
> > But I'd prefer to discuss all the relevant things (that is kpatch
> > unspecific) here. It would make it easier.
>
> And you
On Wed, 6 Apr 2016, Miroslav Benes wrote:
> Anyway I see there are some new comments on github. I'll look at those.
> But I'd prefer to discuss all the relevant things (that is kpatch
> unspecific) here. It would make it easier.
And you do (after seeing dates of the posts there), sorry for the
On Wed, 6 Apr 2016, Miroslav Benes wrote:
> Anyway I see there are some new comments on github. I'll look at those.
> But I'd prefer to discuss all the relevant things (that is kpatch
> unspecific) here. It would make it easier.
And you do (after seeing dates of the posts there), sorry for the
On Tue, 5 Apr 2016, Jessica Yu wrote:
> +++ Miroslav Benes [05/04/16 15:07 +0200]:
> > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> >
> > > So I think this doesn't fix the problem. Dynamic relocations are
> > > applied to the "patch module", whereas the above code deals with the
> > >
On Tue, 5 Apr 2016, Jessica Yu wrote:
> +++ Miroslav Benes [05/04/16 15:07 +0200]:
> > On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> >
> > > So I think this doesn't fix the problem. Dynamic relocations are
> > > applied to the "patch module", whereas the above code deals with the
> > >
On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
>
> > So I think this doesn't fix the problem. Dynamic relocations are
> > applied to the "patch module", whereas the above code deals with the
> > initialization order of the "patched
On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
>
> > So I think this doesn't fix the problem. Dynamic relocations are
> > applied to the "patch module", whereas the above code deals with the
> > initialization order of the "patched
+++ Miroslav Benes [05/04/16 15:07 +0200]:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the "patched module". This distinction
originally
+++ Miroslav Benes [05/04/16 15:07 +0200]:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the "patched module". This distinction
originally
05.04.2016 16:07, Miroslav Benes пишет:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the "patched module". This distinction
originally
05.04.2016 16:07, Miroslav Benes пишет:
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
So I think this doesn't fix the problem. Dynamic relocations are
applied to the "patch module", whereas the above code deals with the
initialization order of the "patched module". This distinction
originally
On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
>
> > So I think this doesn't fix the problem. Dynamic relocations are
> > applied to the "patch module", whereas the above code deals with the
> > initialization order of the "patched
On Tue, Apr 05, 2016 at 03:07:13PM +0200, Miroslav Benes wrote:
> On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
>
> > So I think this doesn't fix the problem. Dynamic relocations are
> > applied to the "patch module", whereas the above code deals with the
> > initialization order of the "patched
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> So I think this doesn't fix the problem. Dynamic relocations are
> applied to the "patch module", whereas the above code deals with the
> initialization order of the "patched module". This distinction
> originally confused me as well, until Jessica
On Mon, 4 Apr 2016, Josh Poimboeuf wrote:
> So I think this doesn't fix the problem. Dynamic relocations are
> applied to the "patch module", whereas the above code deals with the
> initialization order of the "patched module". This distinction
> originally confused me as well, until Jessica
+++ Josh Poimboeuf [04/04/16 11:14 -0500]:
On Fri, Apr 01, 2016 at 09:35:34PM +0200, Jiri Kosina wrote:
On Fri, 1 Apr 2016, Chris J Arges wrote:
> Loading, please wait...
> starting version 229
> [1.182869] random: udevadm urandom read with 2 bits of entropy available
> [1.241404] BUG:
+++ Josh Poimboeuf [04/04/16 11:14 -0500]:
On Fri, Apr 01, 2016 at 09:35:34PM +0200, Jiri Kosina wrote:
On Fri, 1 Apr 2016, Chris J Arges wrote:
> Loading, please wait...
> starting version 229
> [1.182869] random: udevadm urandom read with 2 bits of entropy available
> [1.241404] BUG:
On Fri, Apr 01, 2016 at 09:35:34PM +0200, Jiri Kosina wrote:
> On Fri, 1 Apr 2016, Chris J Arges wrote:
>
> > Loading, please wait...
> > starting version 229
> > [1.182869] random: udevadm urandom read with 2 bits of entropy available
> > [1.241404] BUG: unable to handle kernel paging
On Fri, Apr 01, 2016 at 09:35:34PM +0200, Jiri Kosina wrote:
> On Fri, 1 Apr 2016, Chris J Arges wrote:
>
> > Loading, please wait...
> > starting version 229
> > [1.182869] random: udevadm urandom read with 2 bits of entropy available
> > [1.241404] BUG: unable to handle kernel paging
On Fri, 1 Apr 2016, Chris J Arges wrote:
> Loading, please wait...
> starting version 229
> [1.182869] random: udevadm urandom read with 2 bits of entropy available
> [1.241404] BUG: unable to handle kernel paging request at c000f35f
Gah, we surely can't change pages with RO PTE.
On Fri, 1 Apr 2016, Chris J Arges wrote:
> Loading, please wait...
> starting version 229
> [1.182869] random: udevadm urandom read with 2 bits of entropy available
> [1.241404] BUG: unable to handle kernel paging request at c000f35f
Gah, we surely can't change pages with RO PTE.
On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote:
> On Fri, 1 Apr 2016, Jiri Kosina wrote:
>
> > On Tue, 29 Mar 2016, Jiri Kosina wrote:
> >
> > > Agreed; I think we should be safe applying all the alternatives (with
> > > paravirt being really just a special case of those) to the
On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote:
> On Fri, 1 Apr 2016, Jiri Kosina wrote:
>
> > On Tue, 29 Mar 2016, Jiri Kosina wrote:
> >
> > > Agreed; I think we should be safe applying all the alternatives (with
> > > paravirt being really just a special case of those) to the
On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote:
> On Fri, 1 Apr 2016, Jiri Kosina wrote:
>
> > On Tue, 29 Mar 2016, Jiri Kosina wrote:
> >
> > > Agreed; I think we should be safe applying all the alternatives (with
> > > paravirt being really just a special case of those) to the
On Fri, Apr 01, 2016 at 05:46:52PM +0200, Miroslav Benes wrote:
> On Fri, 1 Apr 2016, Jiri Kosina wrote:
>
> > On Tue, 29 Mar 2016, Jiri Kosina wrote:
> >
> > > Agreed; I think we should be safe applying all the alternatives (with
> > > paravirt being really just a special case of those) to the
On Fri, 1 Apr 2016, Jiri Kosina wrote:
> On Tue, 29 Mar 2016, Jiri Kosina wrote:
>
> > Agreed; I think we should be safe applying all the alternatives (with
> > paravirt being really just a special case of those) to the coming module
> > at the very last phase; they really are required only
On Fri, 1 Apr 2016, Jiri Kosina wrote:
> On Tue, 29 Mar 2016, Jiri Kosina wrote:
>
> > Agreed; I think we should be safe applying all the alternatives (with
> > paravirt being really just a special case of those) to the coming module
> > at the very last phase; they really are required only
On Tue, 29 Mar 2016, Jiri Kosina wrote:
> Agreed; I think we should be safe applying all the alternatives (with
> paravirt being really just a special case of those) to the coming module
> at the very last phase; they really are required only during runtime,
> but nothing else should be
On Tue, 29 Mar 2016, Jiri Kosina wrote:
> Agreed; I think we should be safe applying all the alternatives (with
> paravirt being really just a special case of those) to the coming module
> at the very last phase; they really are required only during runtime,
> but nothing else should be
On Tue, 29 Mar 2016, Miroslav Benes wrote:
> > 1) Jessica proposed using the Arch-independent patchset ensure that
> > livepatch
> > finishes writing its relas before apply_paravirt() is called. However, this
> > introduces a bit more arch-dependent code. It would be useful to see if
> > other
On Tue, 29 Mar 2016, Miroslav Benes wrote:
> > 1) Jessica proposed using the Arch-independent patchset ensure that
> > livepatch
> > finishes writing its relas before apply_paravirt() is called. However, this
> > introduces a bit more arch-dependent code. It would be useful to see if
> > other
[ adding CCs ]
On Tue, 29 Mar 2016, Chris J Arges wrote:
> Paravirtualized ops and livepatching currently don't mix very well and can
> cause undefined behavor such as oops, invalid opcodes or corrupted stacks.
> The original discussion of this issue can be found here [1].
>
> I've written an
[ adding CCs ]
On Tue, 29 Mar 2016, Chris J Arges wrote:
> Paravirtualized ops and livepatching currently don't mix very well and can
> cause undefined behavor such as oops, invalid opcodes or corrupted stacks.
> The original discussion of this issue can be found here [1].
>
> I've written an
Paravirtualized ops and livepatching currently don't mix very well and can
cause undefined behavor such as oops, invalid opcodes or corrupted stacks.
The original discussion of this issue can be found here [1].
I've written an example livepatch module that reproduces the issue [2].
In order to
Paravirtualized ops and livepatching currently don't mix very well and can
cause undefined behavor such as oops, invalid opcodes or corrupted stacks.
The original discussion of this issue can be found here [1].
I've written an example livepatch module that reproduces the issue [2].
In order to
50 matches
Mail list logo
