On Thu, 14 Apr 2016, Josh Poimboeuf wrote:
> On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote:
> > On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
> >
> > > +/*
> > > + * klp_update_task_universe() - change the patched state of a task
> > > + * @task:The task to change
> > > + *
On Thu, 14 Apr 2016, Josh Poimboeuf wrote:
> On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote:
> > On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
> >
> > > +/*
> > > + * klp_update_task_universe() - change the patched state of a task
> > > + * @task:The task to change
> > > + *
On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote:
> On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
>
> > Add a basic per-task consistency model. This is the foundation which
> > will eventually enable us to patch those ~10% of security patches which
> > change function prototypes
On Thu, Apr 14, 2016 at 11:25:18AM +0200, Miroslav Benes wrote:
> On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
>
> > Add a basic per-task consistency model. This is the foundation which
> > will eventually enable us to patch those ~10% of security patches which
> > change function prototypes
On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
> Add a basic per-task consistency model. This is the foundation which
> will eventually enable us to patch those ~10% of security patches which
> change function prototypes and/or data semantics.
>
> When a patch is enabled, livepatch enters into a
On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
> Add a basic per-task consistency model. This is the foundation which
> will eventually enable us to patch those ~10% of security patches which
> change function prototypes and/or data semantics.
>
> When a patch is enabled, livepatch enters into a
On Wed, Apr 06, 2016 at 01:32:48AM +0800, Minfei Huang wrote:
> On 03/25/16 at 02:34P, Josh Poimboeuf wrote:
> > +static int klp_check_stack(struct task_struct *task)
> > +{
> > + static unsigned long entries[MAX_STACK_ENTRIES];
> > + struct stack_trace trace;
> > + struct klp_object *obj;
>
On Wed, Apr 06, 2016 at 01:32:48AM +0800, Minfei Huang wrote:
> On 03/25/16 at 02:34P, Josh Poimboeuf wrote:
> > +static int klp_check_stack(struct task_struct *task)
> > +{
> > + static unsigned long entries[MAX_STACK_ENTRIES];
> > + struct stack_trace trace;
> > + struct klp_object *obj;
>
On 03/25/16 at 02:34P, Josh Poimboeuf wrote:
> +static int klp_check_stack(struct task_struct *task)
> +{
> + static unsigned long entries[MAX_STACK_ENTRIES];
> + struct stack_trace trace;
> + struct klp_object *obj;
> + struct klp_func *func;
> + int ret;
> +
> +
On 03/25/16 at 02:34P, Josh Poimboeuf wrote:
> +static int klp_check_stack(struct task_struct *task)
> +{
> + static unsigned long entries[MAX_STACK_ENTRIES];
> + struct stack_trace trace;
> + struct klp_object *obj;
> + struct klp_func *func;
> + int ret;
> +
> +
On Tue, Apr 05, 2016 at 01:36:34PM +0200, Vojtech Pavlik wrote:
> On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> > On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> > >
> > > > Hm, can you
On Tue, Apr 05, 2016 at 01:36:34PM +0200, Vojtech Pavlik wrote:
> On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> > On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> > >
> > > > Hm, can you
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
> > >
> > > I'm thinking
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
> > >
> > > I'm thinking
On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> Hm, can you explain why it should be copied from the parent?
>
> I'm thinking the above code is correct for today, but it should still be
> changed to be more future-proof.
>
> Here's my thinking:
>
> A forked task starts out
On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> Hm, can you explain why it should be copied from the parent?
>
> I'm thinking the above code is correct for today, but it should still be
> changed to be more future-proof.
>
> Here's my thinking:
>
> A forked task starts out
On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
>
> > Hm, can you explain why it should be copied from the parent?
> >
> > I'm thinking the above code is correct for today, but it should still be
> > changed to be
On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
>
> > Hm, can you explain why it should be copied from the parent?
> >
> > I'm thinking the above code is correct for today, but it should still be
> > changed to be
On Thu, Mar 31, 2016 at 03:12:39PM +0200, Miroslav Benes wrote:
> On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
>
> [...]
>
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index d277e83..27b181e 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -76,6 +76,7 @@
> > #include
> >
On Thu, Mar 31, 2016 at 03:12:39PM +0200, Miroslav Benes wrote:
> On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
>
> [...]
>
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index d277e83..27b181e 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -76,6 +76,7 @@
> > #include
> >
On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
[...]
> diff --git a/kernel/fork.c b/kernel/fork.c
> index d277e83..27b181e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -76,6 +76,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1615,6 +1616,7 @@
On Fri, 25 Mar 2016, Josh Poimboeuf wrote:
[...]
> diff --git a/kernel/fork.c b/kernel/fork.c
> index d277e83..27b181e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -76,6 +76,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -1615,6 +1616,7 @@
Add a basic per-task consistency model. This is the foundation which
will eventually enable us to patch those ~10% of security patches which
change function prototypes and/or data semantics.
When a patch is enabled, livepatch enters into a transition state where
tasks are converging from the old
Add a basic per-task consistency model. This is the foundation which
will eventually enable us to patch those ~10% of security patches which
change function prototypes and/or data semantics.
When a patch is enabled, livepatch enters into a transition state where
tasks are converging from the old
24 matches
Mail list logo
