Re: [RFC 09/16] kgr: mark task_safe in some kthreads

[Vojtech Pavlik]

On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:

> I see the worst case scenario. (For curious readers, it is for example
> this kthread body:
> while (1) {
>   some_paired_call(); /* invokes pre-patched code */
>   if (kthread_should_stop()) { /* kgraft switches to the new code */
>     its_paired_function(); /* invokes patched code (wrong) */
>     break;
>   }
>   its_paired_function(); /* the same (wrong) */
> })
> 
> What to do with that now? We have come up with a couple possibilities.
> Would you consider try_to_freeze() a good state-defining function? As it
> is called when a kthread expects weird things can happen, it should be
> safe to switch to the patched version in our opinion.
> 
> The other possibility is to patch every kthread loop (~300) and insert
> kgr_task_safe() semi-manually at some proper place.
> 
> Or if you have any other suggestions we would appreciate that?

A heretic idea would be to convert all kernel threads into functions
that do not sleep and exit after a single iteration and are called from
a central kthread main loop function. That would get all of
kthread_should_stop() and try_to_freeze() and kgr_task_safe() nicely
into one place and at the same time put enough constraint on what the
thread function can do to prevent it from breaking the assumptions of
each of these calls. 

-- 
Vojtech Pavlik
SUSE Labs
--
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/