* Jiri Kosina wrote:
> On Sat, 21 Feb 2015, Ingo Molnar wrote:
>
> > (It does have some other requirements, such as making
> > all syscalls interruptible to a 'special' signalling
> > method that only live patching triggers - even syscalls
> > that are under the normal ABI uninterruptible, s
On Sat, 21 Feb 2015, Ingo Molnar wrote:
> (It does have some other requirements, such as making all
> syscalls interruptible to a 'special' signalling method
> that only live patching triggers - even syscalls that are
> under the normal ABI uninterruptible, such as sys_sync().)
BTW I didn't re
[ live-patching@ ML added to CC here as well ]
On Sun, 22 Feb 2015, Ingo Molnar wrote:
> > BTW how exactly do you envision this will work? Do I understand your
> > proposal correctly that EINTR will be "handled" somewhere in the "live
> > patching special signal handler" and then have the inte
* Jiri Kosina wrote:
> On Sat, 21 Feb 2015, Ingo Molnar wrote:
>
> > > Plus a lot of processes would see EINTR, causing more
> > > havoc.
> >
> > Parking threads safely in user mode does not require
> > the propagation of syscall interruption to user-space.
>
> BTW how exactly do you envisi
On Sun, 22 Feb 2015, Ingo Molnar wrote:
> I am making specific technical arguments, but you attempted to redirect
> my very specific arguments towards 'differences in philosophy' and
> 'where to draw the line'. Lets discuss the merits and brush them aside
> as 'philosophical differences' or a m
On Sat, 21 Feb 2015, Ingo Molnar wrote:
> > Plus a lot of processes would see EINTR, causing more havoc.
>
> Parking threads safely in user mode does not require the propagation of
> syscall interruption to user-space.
BTW how exactly do you envision this will work? Do I understand your
propos
* Jiri Kosina wrote:
> > > Or think of kernel that has some 3rd party vendor
> > > module loaded, and this module spawning a ktrehad
> > > that is not capable of parking itself.
> >
> > The kernel will refuse to live patch until the module
> > is fixed. It is a win by any measure.
>
> Depen
To make sure that this thread doesn't conclude in void, here's my take on
it:
- what's currently alredy there is the simplest-of-simplest methods; it
allows you to apply context-less patches (such as adding bounds checking
to the beginning of syscall, etc), which turns out to cover vast port
On Sat, 21 Feb 2015, Ingo Molnar wrote:
> > I see the difference, but I am afraid you are simplifying
> > the situation a litle bit too much.
> >
> > There will always be properties of patches that will make
> > them unapplicable in a "live patching" way by design.
> > Think of data structure
* Jiri Kosina wrote:
> On Sat, 21 Feb 2015, Ingo Molnar wrote:
>
> > > But admittedly, if we reserve a special sort-of
> > > signal for making the tasks pass through a safe
> > > checkpoint (and make them queue there (your solution)
> > > or make them just pass through it and continue
> > >
On Sat, 21 Feb 2015, Ingo Molnar wrote:
> > But admittedly, if we reserve a special sort-of signal
> > for making the tasks pass through a safe checkpoint (and
> > make them queue there (your solution) or make them just
> > pass through it and continue (current kGraft)), it might
> > reduce th
* Jiri Kosina wrote:
> On Sat, 21 Feb 2015, Ingo Molnar wrote:
>
> > > This means that each and every sleeping task in the
> > > system has to be woken up in some way (sending a
> > > signal ...) to exit from a syscall it is sleeping in.
> > > Same for CPU hogs. All kernel threads need to be
On Sat, 21 Feb 2015, Ingo Molnar wrote:
> > This means that each and every sleeping task in the system has to be
> > woken up in some way (sending a signal ...) to exit from a syscall it
> > is sleeping in. Same for CPU hogs. All kernel threads need to be
> > parked.
>
> Yes - although I'd not
* Josh Poimboeuf wrote:
> On Fri, Feb 20, 2015 at 10:46:13PM +0100, Vojtech Pavlik wrote:
> > On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote:
> >
> > > I.e. it's in essence the strong stop-all atomic
> > > patching model of 'kpatch', combined with the
> > > reliable avoidance of k
* Vojtech Pavlik wrote:
> On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote:
>
> > > ... the choice the sysadmins have here is either have
> > > the system running in an intermediate state, or have
> > > the system completely dead for the *same time*.
> > > Because to finish the tr
On Fri, Feb 20, 2015 at 10:46:13PM +0100, Vojtech Pavlik wrote:
> On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote:
> > I.e. it's in essence the strong stop-all atomic patching
> > model of 'kpatch', combined with the reliable avoidance of
> > kernel stacks that 'kgraft' uses.
>
> > T
On Fri, Feb 20, 2015 at 08:49:01PM +0100, Ingo Molnar wrote:
> > ... the choice the sysadmins have here is either have the
> > system running in an intermediate state, or have the
> > system completely dead for the *same time*. Because to
> > finish the transition successfully, all the tasks ha
On Fri, Feb 20, 2015 at 09:08:49PM +0100, Ingo Molnar wrote:
> * Josh Poimboeuf wrote:
> > On Fri, Feb 20, 2015 at 10:50:03AM +0100, Ingo Molnar wrote:
> > > * Jiri Kosina wrote:
> > >
> > > > Alright, so to sum it up:
> > > >
> > > > - current stack dumping (even looking at /proc//stack) is no
* Josh Poimboeuf wrote:
> On Fri, Feb 20, 2015 at 10:50:03AM +0100, Ingo Molnar wrote:
> >
> > * Jiri Kosina wrote:
> >
> > > Alright, so to sum it up:
> > >
> > > - current stack dumping (even looking at /proc//stack) is not
> > > guaranteed to yield "correct" results in case the task is
* Jiri Kosina wrote:
> > All fundamental pieces of the simple method are
> > necessary to get guaranteed time transition from the
> > complicated method: task tracking and transparent
> > catching of them, handling kthreads, etc.
> >
> > My argument is that the simple method should be
> > i
On Fri, Feb 20, 2015 at 09:49:32AM +0100, Jiri Kosina wrote:
> Alright, so to sum it up:
>
> - current stack dumping (even looking at /proc//stack) is not
> guaranteed to yield "correct" results in case the task is running at the
> time the stack is being examined
>
> - the only fool-proof
On Fri, Feb 20, 2015 at 10:50:03AM +0100, Ingo Molnar wrote:
>
> * Jiri Kosina wrote:
>
> > Alright, so to sum it up:
> >
> > - current stack dumping (even looking at /proc//stack) is not
> > guaranteed to yield "correct" results in case the task is running at the
> > time the stack is be
On Fri, 20 Feb 2015, Ingo Molnar wrote:
> - the complicated method spread out over time: uses the
> same essential mechanism plus the ftrace patching
> machinery to detect whether all tasks have transitioned
> through a version flip. [this is what kgraft does in
> part.]
The
* Jiri Kosina wrote:
> On Fri, 20 Feb 2015, Ingo Molnar wrote:
>
> > So if your design is based on being able to discover
>
> > 'live' functions in the kernel stack dump of all tasks
> > in the system, I think you need a serious reboot of the
> > whole approach and get rid of that fragility
On Fri, 20 Feb 2015, Ingo Molnar wrote:
> So if your design is based on being able to discover 'live' functions in
> the kernel stack dump of all tasks in the system, I think you need a
> serious reboot of the whole approach and get rid of that fragility
> before any of that functionality gets
* Jiri Kosina wrote:
> Alright, so to sum it up:
>
> - current stack dumping (even looking at /proc//stack) is not
> guaranteed to yield "correct" results in case the task is running at the
> time the stack is being examined
Don't even _think_ about trying to base something as
dangerous
Alright, so to sum it up:
- current stack dumping (even looking at /proc//stack) is not
guaranteed to yield "correct" results in case the task is running at the
time the stack is being examined
- the only fool-proof way is to send IPI-NMI to all CPUs, and synchronize
the handlers between
On Thu, 19 Feb 2015, Josh Poimboeuf wrote:
> So I've looked at kgr_needs_lazy_migration(), but I still have no idea
> how it works.
>
> First of all, I think reading the stack while its being written to could
> give you some garbage values, and a completely wrong nr_entries value
> from save_stac
On Thu, Feb 19, 2015 at 10:26:09PM +0100, Jiri Kosina wrote:
> On Thu, 19 Feb 2015, Josh Poimboeuf wrote:
>
> > How about with a TIF_IN_USERSPACE thread flag? It could be cleared/set
> > right at the border. Then for running tasks it's as simple as:
> >
> > if (test_tsk_thread_flag(task, TIF_IN
On Thu, Feb 19, 2015 at 09:40:36PM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> > > On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > > > On Thu, Feb 19, 2015 at
On Thu, 19 Feb 2015, Jiri Kosina wrote:
> > How about with a TIF_IN_USERSPACE thread flag? It could be cleared/set
> > right at the border. Then for running tasks it's as simple as:
> >
> > if (test_tsk_thread_flag(task, TIF_IN_USERSPACE))
> > klp_switch_task_universe(task);
>
> That's in
On Thu, 19 Feb 2015, Josh Poimboeuf wrote:
> How about with a TIF_IN_USERSPACE thread flag? It could be cleared/set
> right at the border. Then for running tasks it's as simple as:
>
> if (test_tsk_thread_flag(task, TIF_IN_USERSPACE))
> klp_switch_task_universe(task);
That's in principle
On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > > > On Thu, Feb 19, 2015 at
On February 19, 2015 6:32:55 PM CET, Josh Poimboeuf wrote:
>> Yes. I'm saying that rather than guaranteeing they don't enter the
>> kernel (by having them spin) you can flip them in case they try to do
>> that instead. That solves the race condition just as well.
>
>Ok, gotcha.
>
>We'd still need
On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> > >
> > > > > No, these task
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> >
> > > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > > they don't
On Thu, 19 Feb 2015, Josh Poimboeuf wrote:
> > > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > > they don't accidentally enter the kernel while you flip them. Something
> > > > like so should do.
> > > >
> > > > You set TIF_ENTER_WAIT on them, check they're still in
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
>
> > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > they don't accidentally enter the kernel while you flip them. Something
> > > like so
On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> > No, these tasks will _never_ make syscalls. So you need to guarantee
> > they don't accidentally enter the kernel while you flip them. Something
> > like so should do.
> >
> > You set TIF_ENTER_WAIT on them, check they're still i
On Thu, Feb 19, 2015 at 11:16:07AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 10:17:53PM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 19, 2015 at 01:20:58AM +0100, Peter Zijlstra wrote:
> > > On Wed, Feb 18, 2015 at 11:12:56AM -0600, Josh Poimboeuf wrote:
>
> > > > The next line of att
On Wed, Feb 18, 2015 at 10:17:53PM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 01:20:58AM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 18, 2015 at 11:12:56AM -0600, Josh Poimboeuf wrote:
> > > The next line of attack is patching tasks when exiting the kernel to
> > > user space (system
On Thu, Feb 19, 2015 at 01:20:58AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 11:12:56AM -0600, Josh Poimboeuf wrote:
> > > So uhm, what happens if your target task is running? When will you
> > > retry? The problem I see is that if you do a sample approach you might
> > > never hit an
On Wed, Feb 18, 2015 at 11:12:56AM -0600, Josh Poimboeuf wrote:
> > > a) spend the time to ensure the unwinding code is correct and resilient
> > >to errors;
> > >
> > > b) leave the consistency model compiled code out if !FRAME_POINTER and
> > >allow users to patch without one (similar t
On Wed, Feb 18, 2015 at 04:21:00PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 03:25:32PM -0600, Josh Poimboeuf wrote:
> > > And I'm assuming you're hard relying on CONFIG_FRAMEPOINTER here,
> > > because otherwise x86 stacks are a mess too.
> >
> > Yeah, it'll rely on CONFIG_FRAME_POIN
On Tue, Feb 17, 2015 at 03:25:32PM -0600, Josh Poimboeuf wrote:
> > And I'm assuming you're hard relying on CONFIG_FRAMEPOINTER here,
> > because otherwise x86 stacks are a mess too.
>
> Yeah, it'll rely on CONFIG_FRAME_POINTER. IIUC, the arches we care
> about now (x86, power, s390, arm64) all h
On Tue, Feb 17, 2015 at 07:15:41PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 08:12:11AM -0600, Josh Poimboeuf wrote:
> > On Tue, Feb 17, 2015 at 10:24:50AM +0100, Peter Zijlstra wrote:
> > > So far stack unwinding has basically been a best effort debug output
> > > kind of thing, you'r
On Tue, Feb 17, 2015 at 08:12:11AM -0600, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2015 at 10:24:50AM +0100, Peter Zijlstra wrote:
> > So far stack unwinding has basically been a best effort debug output
> > kind of thing, you're wanting to make the integrity of the kernel depend
> > on it.
> >
> >
On Tue, Feb 17, 2015 at 10:24:50AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 16, 2015 at 04:05:05PM -0600, Josh Poimboeuf wrote:
> > Yeah, I can understand that. I definitely want to avoid touching the
> > scheduler code. Basically I'm trying to find a way to atomically do the
> > following:
> >
On Mon, Feb 16, 2015 at 04:05:05PM -0600, Josh Poimboeuf wrote:
> Yeah, I can understand that. I definitely want to avoid touching the
> scheduler code. Basically I'm trying to find a way to atomically do the
> following:
>
> if (task is sleeping) {
> walk the stack
> if (certain set
On Mon, Feb 16, 2015 at 09:44:36PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 16, 2015 at 12:52:34PM -0600, Josh Poimboeuf wrote:
> > +++ b/kernel/sched/core.c
> > @@ -1338,6 +1338,23 @@ void kick_process(struct task_struct *p)
> > EXPORT_SYMBOL_GPL(kick_process);
> > #endif /* CONFIG_SMP */
> >
On Mon, Feb 16, 2015 at 12:52:34PM -0600, Josh Poimboeuf wrote:
> +++ b/kernel/sched/core.c
> @@ -1338,6 +1338,23 @@ void kick_process(struct task_struct *p)
> EXPORT_SYMBOL_GPL(kick_process);
> #endif /* CONFIG_SMP */
>
> +/***
> + * sched_task_call - call a function with a task's state locked
51 matches
Mail list logo
