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 c
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
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 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:
> >
> > "Th
* 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 but
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 Bene
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 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
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
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 da
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 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 tran
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 cod
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, 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 tog
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 start
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 in
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 th
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
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 point
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 mo
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
> > s
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 infra
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 = container_of(f
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 exam
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 se
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
> > +++ b/kernel/live
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, livepat
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/
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 tra
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 transi
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
47 matches
Mail list logo
