Re: [RFC][PATCH] sched,livepatch: Untangle cond_resched() and live-patching

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Mar 26, 2025 at 10:49:10AM +0100, Petr Mladek wrote:
> On Mon 2025-03-24 14:49:09, Peter Zijlstra wrote:
> > 
> > With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> > needs to stop relying on cond_resched() to make forward progress.
> > 
> > Instead, rely on schedule() with TASK_FREEZABLE set. Just like
> > live-patching, the freezer needs to be able to stop tasks in a safe /
> > known state.
> 
> > Compile tested only.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >  include/linux/livepatch_sched.h | 15 +++++--------
> >  include/linux/sched.h           |  6 -----
> >  kernel/livepatch/transition.c   | 30 ++++++-------------------
> >  kernel/sched/core.c             | 50 +++++++----------------------------------
> >  4 files changed, 21 insertions(+), 80 deletions(-)
> > 
> > diff --git a/include/linux/livepatch_sched.h b/include/linux/livepatch_sched.h
> > index 013794fb5da0..7e8171226dd7 100644
> > --- a/include/linux/livepatch_sched.h
> > +++ b/include/linux/livepatch_sched.h
> > @@ -3,27 +3,24 @@
> >  #define _LINUX_LIVEPATCH_SCHED_H_
> >  
> >  #include <linux/jump_label.h>
> > -#include <linux/static_call_types.h>
> > +#include <linux/sched.h>
> > +
> >  
> >  #ifdef CONFIG_LIVEPATCH
> >  
> >  void __klp_sched_try_switch(void);
> >  
> > -#if !defined(CONFIG_PREEMPT_DYNAMIC) || !defined(CONFIG_HAVE_PREEMPT_DYNAMIC_CALL)
> > -
> >  DECLARE_STATIC_KEY_FALSE(klp_sched_try_switch_key);
> >  
> > -static __always_inline void klp_sched_try_switch(void)
> > +static __always_inline void klp_sched_try_switch(struct task_struct *curr)
> >  {
> > -	if (static_branch_unlikely(&klp_sched_try_switch_key))
> > +	if (static_branch_unlikely(&klp_sched_try_switch_key) &&
> > +	    READ_ONCE(curr->__state) & TASK_FREEZABLE)
> >  		__klp_sched_try_switch();
> >  }
> 
> Do we really need to check the TASK_FREEZABLE state, please?
> 
> My understanding is that TASK_FREEZABLE is set when kernel kthreads go into
> a "freezable" sleep, e.g. wait_event_freezable().

Right.

> But __klp_sched_try_switch() should be safe when the task is not
> running and the stack is reliable. IMHO, it should be safe anytime
> it is being scheduled out.

So for the reasons you touched upon in the next paragraph, FREEZABLE
seemed like a more suitable location.

> Note that wait_event_freezable() is a good location. It is usually called in
> the main loop of the kthread where the stack is small. So that the chance
> that it is not running a livepatched function is higher than on
> another random schedulable location.

Right, it is the natural quiescent state of the kthread, it holds no
resources.

> But we actually wanted to have it in cond_resched() because
> it might take a long time to reach the main loop, and sleep there.

Well, cond_resched() is going to get deleted, so we need to find
something else. And I was thinking that the suspend people want
reasonable timeliness too -- you don't want your laptop to continue
running for many seconds after you close the lid and stuff it in your
bag, now do you.

So per that reasoning I figured FREEZABLE should be good enough.

Sharing the pain with suspend can only lead to improving both -- faster
patching progress leads to faster suspend and vice-versa.