Re: [PATCH 1/3] sched: add sched_task_call()

[Peter Zijlstra]

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 to the livepatch code
> > >    that's already in the livepatch tree today); or
> > 
> > Which has a much more limited set of patches it can do, right?
> 
> If we're talking security patches, roughly 9 out of 10 of them don't
> change function prototypes, data, or data semantics.  If the patch
> author is careful, he or she doesn't need a consistency model in those
> cases.
> 
> So it's not _overly_ limited.  If somebody's not happy about those
> limitations, they can put in the work for option a :-)

OK. So all this is really only about really funny bits.

> > 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 opportune moment.
> 
> We attack it from multiple angles.
> 
> First we check the stack of all sleeping tasks.  That patches the
> majority of tasks immediately.  If necessary, we also do that
> periodically in a workqueue to catch any stragglers.

So not only do you need an 'atomic' stack save, you need to analyze and
flip its state in the same atomic region. The task cannot start running
again after the save and start using old functions while you analyze the
stack and flip it.

> The next line of attack is patching tasks when exiting the kernel to
> user space (system calls, interrupts, signals), to catch all CPU-bound
> and some I/O-bound tasks.  That's done in patch 9 [1] of the consistency
> model patch set.

So the HPC people are really into userspace that does for (;;) ; and
isolate that on CPUs and have the tick interrupt stopped and all that.

You'll not catch those threads on the sysexit path.

And I'm fairly sure they'll not want to SIGSTOP/CONT their stuff either.

Now its fairly easy to also handle this; just mark those tasks with a
_TIF_WORK_SYSCALL_ENTRY flag, have that slowpath wait for the flag to
go-away, then flip their state and clear the flag.

> As a last resort, if there are still any tasks which are sleeping on a
> to-be-patched function, the user can send them SIGSTOP and SIGCONT to
> force them to be patched.

You typically cannot SIGSTOP/SIGCONT kernel threads. Also
TASK_UNINTERRUPTIBLE sleeps are unaffected by signals.

Bit pesky that.. needs pondering.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/