On Thu, Feb 19, 2015 at 11:11:53AM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
> > kthread_park() functionality seems to be exactly what you want.
>
> It might be exactly that, indeed. The requrement of not just cleaning
> up, but also not using
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
> > For live patching it doesn't matter whether code is running, sleeping or
> > frozen.
> >
> > What matters is whether there is state before patching that may not
On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
> For live patching it doesn't matter whether code is running, sleeping or
> frozen.
>
> What matters is whether there is state before patching that may not be
> valid after patching.
>
> For userspace tasks, the exit from a syscall
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
For live patching it doesn't matter whether code is running, sleeping or
frozen.
What matters is whether there is state before patching that may not be
valid
On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
For live patching it doesn't matter whether code is running, sleeping or
frozen.
What matters is whether there is state before patching that may not be
valid after patching.
For userspace tasks, the exit from a syscall is a
On Thu, Feb 19, 2015 at 11:11:53AM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
kthread_park() functionality seems to be exactly what you want.
It might be exactly that, indeed. The requrement of not just cleaning
up, but also not using
On Wed, Feb 18, 2015 at 09:17:55PM +0100, Ingo Molnar wrote:
>
> * Jiri Kosina wrote:
>
> > On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> >
> > > And what's wrong with using known good spots like the freezer?
> >
> > Quoting Tejun from the thread Jiri Slaby likely had on
> > mind:
> >
> >
* Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
>
> > And what's wrong with using known good spots like the freezer?
>
> Quoting Tejun from the thread Jiri Slaby likely had on
> mind:
>
> "The fact that they may coincide often can be useful as a
> guideline or whatever
On Wed, 18 Feb 2015, Josh Poimboeuf wrote:
> On Wed, Feb 18, 2015 at 01:42:56PM +0100, Miroslav Benes wrote:
> > On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> >
> > > On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
> > > > On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> > > >
> > >
On Wed, Feb 18, 2015 at 01:42:56PM +0100, Miroslav Benes wrote:
> On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
>
> > On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
> > > On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> > >
> > > > On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
> > On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> >
> > > On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
>
> > > > and externs for functions are redundant.
> > >
> > > I
On Wed, Feb 18, 2015 at 09:17:55PM +0100, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
And what's wrong with using known good spots like the freezer?
Quoting Tejun from the thread Jiri Slaby likely had on
mind:
The
* Jiri Kosina jkos...@suse.cz wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
And what's wrong with using known good spots like the freezer?
Quoting Tejun from the thread Jiri Slaby likely had on
mind:
The fact that they may coincide often can be useful as a
guideline or
On Wed, 18 Feb 2015, Josh Poimboeuf wrote:
On Wed, Feb 18, 2015 at 01:42:56PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Mon, Feb 16,
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
and externs for functions are redundant.
I agree, but it
On Wed, Feb 18, 2015 at 01:42:56PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
> On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
>
> > On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
> > > On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
> > >
>
> [...]
>
> > > > +
> > > > +void
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
> On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
> > On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
> >
[...]
> > > +
> > > +void klp_unpatch_objects(struct klp_patch *patch)
> > > +{
> > > + struct klp_object *obj;
> > > +
> > > + for
On Sat, Feb 14, 2015 at 12:40:01PM +0100, Jiri Slaby wrote:
> On 02/09/2015, 06:31 PM, 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
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
> On Mon, 9 Feb 2015, 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
On Tue, Feb 17, 2015 at 04:48:39PM +0100, Miroslav Benes wrote:
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
+
+void klp_unpatch_objects(struct klp_patch *patch)
On Sat, Feb 14, 2015 at 12:40:01PM +0100, Jiri Slaby wrote:
On 02/09/2015, 06:31 PM, 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
On Tue, 17 Feb 2015, Josh Poimboeuf wrote:
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
+
+void klp_unpatch_objects(struct klp_patch *patch)
+{
+ struct klp_object *obj;
+
+ for (obj = patch-objs;
On Mon, Feb 16, 2015 at 03:19:10PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, 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
On Mon, 9 Feb 2015, 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 Mon, 9 Feb 2015, 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 02/09/2015, 06:31 PM, 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 02/09/2015, 06:31 PM, 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 Thu, Feb 12, 2015 at 02:26:42PM +0100, Jiri Slaby wrote:
> On 02/12/2015, 04:21 AM, Josh Poimboeuf wrote:
> > Ingo, Peter,
> >
> > Would you have any objections to making task_rq_lock/unlock() non-static
> > (or moving them to kernel/sched/sched.h) so they can be called by the
> > livepatch
On Thu, Feb 12, 2015 at 03:08:38PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> I personally am not a big fan of the task_rq_lock() public exposure
> either. What might be generally useful though (not only for livepatching)
> would be an API that would allow for
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> And what's wrong with using known good spots like the freezer?
Quoting Tejun from the thread Jiri Slaby likely had on mind:
"The fact that they may coincide often can be useful as a guideline or
whatever but I'm completely against just mushing it
On Thu, 12 Feb 2015, Josh Poimboeuf wrote:
> > and you have a livepatch patching foo() and changing its return value
> > semantics. Then freezer doesn't really help.
>
> Don't we have the same issue with livepatch? For example:
>
> while (some_condition) {
> ret = foo();
> ...
>
On Thu, Feb 12, 2015 at 02:16:07PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
>
> > > The short answer is: I need a way to ensure that a task isn't sleeping
> > > on any of the functions we're trying to patch. If it's not, then I can
> > > switch the task over to
On 02/12/2015, 02:35 PM, Peter Zijlstra wrote:
> On Thu, Feb 12, 2015 at 02:16:28PM +0100, Jiri Slaby wrote:
>>> And what's wrong with using known good spots like the freezer?
>>
>> This was already discussed too. Please STA.
>
> WTF is STA? You guys want something from me; I don't have time, not
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > > And what's wrong with using known good spots like the freezer?
> >
> > This was already discussed too. Please STA.
>
> WTF is STA? You guys want something from me; I don't have time, not
> inclination to go hunt down whatever dark corner of the
On Thu, Feb 12, 2015 at 02:16:28PM +0100, Jiri Slaby wrote:
> > And what's wrong with using known good spots like the freezer?
>
> This was already discussed too. Please STA.
WTF is STA? You guys want something from me; I don't have time, not
inclination to go hunt down whatever dark corner of
On 02/12/2015, 04:21 AM, Josh Poimboeuf wrote:
> Ingo, Peter,
>
> Would you have any objections to making task_rq_lock/unlock() non-static
> (or moving them to kernel/sched/sched.h) so they can be called by the
> livepatch code?
>
> To provide some background, I'm looking for a way to
Hi,
On 02/12/2015, 02:08 PM, Peter Zijlstra wrote:
> How can one task run new and another task old functions?
because this is how it is designed to work in one of the consistency models.
> Once you patch
> any indirect function pointer any task will see the new call.
It does not patch any
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > The short answer is: I need a way to ensure that a task isn't sleeping
> > on any of the functions we're trying to patch. If it's not, then I can
> > switch the task over to start using new versions of functions.
> >
> > Obviously, there are many
On Thu, Feb 12, 2015 at 06:51:49AM -0600, Josh Poimboeuf wrote:
> > > To provide some background, I'm looking for a way to temporarily prevent
> > > a sleeping task from running while its stack is examined, to decide
> > > whether it can be safely switched to the new patching "universe". For
> >
On Thu, Feb 12, 2015 at 01:42:01PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
>
> > > Well, the fact indisputable fact is that there is a demand for this. It's
> > > not about one machine, it's about scheduling dowtimes of datacentres.
> >
> > The changelog says:
> >
On Thu, Feb 12, 2015 at 12:56:28PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 11, 2015 at 09:21:21PM -0600, Josh Poimboeuf wrote:
> > Ingo, Peter,
> >
> > Would you have any objections to making task_rq_lock/unlock() non-static
> > (or moving them to kernel/sched/sched.h) so they can be called by
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > Well, the fact indisputable fact is that there is a demand for this. It's
> > not about one machine, it's about scheduling dowtimes of datacentres.
>
> The changelog says:
>
> > ... A patch can remain in the
> > transition state indefinitely, if
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > > FWIW, the barriers in klp_update_task_universe() and
> > > klp_set_universe_goal() look like complete crack, and their comments are
> > > seriously deficient.
> >
> > These particular barriers seem correct to me; you basically need to make
> >
On Thu, Feb 12, 2015 at 01:25:14PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
>
> > Its not at all clear how all this would work to me. And I'm not
> > motivated enough to go try and reverse engineer your patch; IMO
> > livepatching is utter fail.
> >
> > If your
On Thu, Feb 12, 2015 at 01:25:14PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> > FWIW, the barriers in klp_update_task_universe() and
> > klp_set_universe_goal() look like complete crack, and their comments are
> > seriously deficient.
>
> These particular barriers
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
> Its not at all clear how all this would work to me. And I'm not
> motivated enough to go try and reverse engineer your patch; IMO
> livepatching is utter fail.
>
> If your infrastructure relies on the uptime of a single machine you've
> lost already.
On Wed, Feb 11, 2015 at 09:21:21PM -0600, Josh Poimboeuf wrote:
> Ingo, Peter,
>
> Would you have any objections to making task_rq_lock/unlock() non-static
> (or moving them to kernel/sched/sched.h) so they can be called by the
> livepatch code?
Basically yes. I really don't want to expose that.
On Wed, 11 Feb 2015, Josh Poimboeuf wrote:
> On Wed, Feb 11, 2015 at 11:21:51AM +0100, Miroslav Benes wrote:
> >
> > On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
> >
> > [...]
> >
> > > @@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long
> > > ip,
> > > ops =
On Wed, Feb 11, 2015 at 09:21:21PM -0600, Josh Poimboeuf wrote:
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
livepatch code?
Basically yes. I really don't want to expose that. And
On Wed, 11 Feb 2015, Josh Poimboeuf wrote:
On Wed, Feb 11, 2015 at 11:21:51AM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
@@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long
ip,
ops = container_of(fops, struct
On Thu, Feb 12, 2015 at 06:51:49AM -0600, Josh Poimboeuf wrote:
To provide some background, I'm looking for a way to temporarily prevent
a sleeping task from running while its stack is examined, to decide
whether it can be safely switched to the new patching universe. For
more details
On Thu, Feb 12, 2015 at 02:16:28PM +0100, Jiri Slaby wrote:
And what's wrong with using known good spots like the freezer?
This was already discussed too. Please STA.
WTF is STA? You guys want something from me; I don't have time, not
inclination to go hunt down whatever dark corner of the
On Thu, Feb 12, 2015 at 02:16:07PM +0100, Jiri Kosina wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
The short answer is: I need a way to ensure that a task isn't sleeping
on any of the functions we're trying to patch. If it's not, then I can
switch the task over to start using new
On Thu, 12 Feb 2015, Josh Poimboeuf wrote:
and you have a livepatch patching foo() and changing its return value
semantics. Then freezer doesn't really help.
Don't we have the same issue with livepatch? For example:
while (some_condition) {
ret = foo();
...
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
And what's wrong with using known good spots like the freezer?
This was already discussed too. Please STA.
WTF is STA? You guys want something from me; I don't have time, not
inclination to go hunt down whatever dark corner of the interweb
On 02/12/2015, 02:35 PM, Peter Zijlstra wrote:
On Thu, Feb 12, 2015 at 02:16:28PM +0100, Jiri Slaby wrote:
And what's wrong with using known good spots like the freezer?
This was already discussed too. Please STA.
WTF is STA? You guys want something from me; I don't have time, not
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
And what's wrong with using known good spots like the freezer?
Quoting Tejun from the thread Jiri Slaby likely had on mind:
The fact that they may coincide often can be useful as a guideline or
whatever but I'm completely against just mushing it
On Thu, Feb 12, 2015 at 12:56:28PM +0100, Peter Zijlstra wrote:
On Wed, Feb 11, 2015 at 09:21:21PM -0600, Josh Poimboeuf wrote:
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
On Thu, Feb 12, 2015 at 01:42:01PM +0100, Jiri Kosina wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
Well, the fact indisputable fact is that there is a demand for this. It's
not about one machine, it's about scheduling dowtimes of datacentres.
The changelog says:
... A
Hi,
On 02/12/2015, 02:08 PM, Peter Zijlstra wrote:
How can one task run new and another task old functions?
because this is how it is designed to work in one of the consistency models.
Once you patch
any indirect function pointer any task will see the new call.
It does not patch any
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
The short answer is: I need a way to ensure that a task isn't sleeping
on any of the functions we're trying to patch. If it's not, then I can
switch the task over to start using new versions of functions.
Obviously, there are many more
On 02/12/2015, 04:21 AM, Josh Poimboeuf wrote:
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
livepatch code?
To provide some background, I'm looking for a way to temporarily
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
Well, the fact indisputable fact is that there is a demand for this. It's
not about one machine, it's about scheduling dowtimes of datacentres.
The changelog says:
... A patch can remain in the
transition state indefinitely, if any of the
On Thu, Feb 12, 2015 at 01:25:14PM +0100, Jiri Kosina wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
FWIW, the barriers in klp_update_task_universe() and
klp_set_universe_goal() look like complete crack, and their comments are
seriously deficient.
These particular barriers seem
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
Its not at all clear how all this would work to me. And I'm not
motivated enough to go try and reverse engineer your patch; IMO
livepatching is utter fail.
If your infrastructure relies on the uptime of a single machine you've
lost already.
Well,
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
FWIW, the barriers in klp_update_task_universe() and
klp_set_universe_goal() look like complete crack, and their comments are
seriously deficient.
These particular barriers seem correct to me; you basically need to make
sure that
On Thu, Feb 12, 2015 at 01:25:14PM +0100, Jiri Kosina wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
Its not at all clear how all this would work to me. And I'm not
motivated enough to go try and reverse engineer your patch; IMO
livepatching is utter fail.
If your infrastructure
On Thu, Feb 12, 2015 at 03:08:38PM +0100, Jiri Kosina wrote:
On Thu, 12 Feb 2015, Peter Zijlstra wrote:
I personally am not a big fan of the task_rq_lock() public exposure
either. What might be generally useful though (not only for livepatching)
would be an API that would allow for safe
On Thu, Feb 12, 2015 at 02:26:42PM +0100, Jiri Slaby wrote:
On 02/12/2015, 04:21 AM, Josh Poimboeuf wrote:
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
livepatch code?
To
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
livepatch code?
To provide some background, I'm looking for a way to temporarily prevent
a sleeping task from running while its stack is
On Wed, Feb 11, 2015 at 05:28:13PM +0100, Miroslav Benes wrote:
> On Tue, 10 Feb 2015, Josh Poimboeuf wrote:
>
> > On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
> > >
> > > On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
> > >
> > > > Add a basic per-task consistency model. This is
On Wed, Feb 11, 2015 at 11:21:51AM +0100, Miroslav Benes wrote:
>
> On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
>
> [...]
>
> > @@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> > ops = container_of(fops, struct klp_ops, fops);
> >
> > rcu_read_lock();
> > +
On Tue, 10 Feb 2015, Josh Poimboeuf wrote:
> On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
> >
> > On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
> >
> > > Add a basic per-task consistency model. This is the foundation which
> > > will eventually enable us to patch those ~10% of
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
> @@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> ops = container_of(fops, struct klp_ops, fops);
>
> rcu_read_lock();
> +
> func = list_first_or_null_rcu(>func_stack, struct klp_func,
>
On Tue, 10 Feb 2015, Josh Poimboeuf wrote:
On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, 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
On Wed, Feb 11, 2015 at 05:28:13PM +0100, Miroslav Benes wrote:
On Tue, 10 Feb 2015, Josh Poimboeuf wrote:
On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
Add a basic per-task consistency model. This is the foundation
On Wed, Feb 11, 2015 at 11:21:51AM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
@@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long ip,
ops = container_of(fops, struct klp_ops, fops);
rcu_read_lock();
+
func =
Ingo, Peter,
Would you have any objections to making task_rq_lock/unlock() non-static
(or moving them to kernel/sched/sched.h) so they can be called by the
livepatch code?
To provide some background, I'm looking for a way to temporarily prevent
a sleeping task from running while its stack is
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
@@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long ip,
ops = container_of(fops, struct klp_ops, fops);
rcu_read_lock();
+
func = list_first_or_null_rcu(ops-func_stack, struct klp_func,
On Tue, Feb 10, 2015 at 01:27:59PM -0600, Seth Jennings wrote:
> On Mon, Feb 09, 2015 at 11:31:18AM -0600, Josh Poimboeuf wrote:
> > diff --git a/kernel/livepatch/transition.h b/kernel/livepatch/transition.h
> > new file mode 100644
> > index 000..ba9a55c
> > --- /dev/null
> > +++
On Mon, Feb 09, 2015 at 11:31:18AM -0600, 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,
On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
>
> On Mon, 9 Feb 2015, 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 Mon, 9 Feb 2015, 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 Tue, Feb 10, 2015 at 07:58:30PM +0900, Masami Hiramatsu wrote:
> (2015/02/10 2:31), Josh Poimboeuf wrote:
> > +/*
> > + * Try to safely transition a task to the universe goal. If the task is
> > + * currently running or is sleeping on a to-be-patched or to-be-unpatched
> > + * function, return
(2015/02/10 2:31), 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 Mon, 9 Feb 2015, 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 Tue, Feb 10, 2015 at 07:58:30PM +0900, Masami Hiramatsu wrote:
(2015/02/10 2:31), Josh Poimboeuf wrote:
+/*
+ * Try to safely transition a task to the universe goal. If the task is
+ * currently running or is sleeping on a to-be-patched or to-be-unpatched
+ * function, return false.
On Tue, Feb 10, 2015 at 04:59:17PM +0100, Miroslav Benes wrote:
On Mon, 9 Feb 2015, 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
(2015/02/10 2:31), 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 transition
On Mon, Feb 09, 2015 at 11:31:18AM -0600, 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
On Tue, Feb 10, 2015 at 01:27:59PM -0600, Seth Jennings wrote:
On Mon, Feb 09, 2015 at 11:31:18AM -0600, Josh Poimboeuf wrote:
diff --git a/kernel/livepatch/transition.h b/kernel/livepatch/transition.h
new file mode 100644
index 000..ba9a55c
--- /dev/null
+++
92 matches
Mail list logo
