[PATCH] um: add RCU syscall hack for time-travel

Richard Weinberger richard.weinberger at gmail.com
Thu Sep 12 12:02:11 PDT 2024


On Fri, Aug 30, 2024 at 5:38 PM Benjamin Berg <benjamin at sipsolutions.net> wrote:
>
> From: Benjamin Berg <benjamin.berg at intel.com>
>
> In time-travel mode userspace can do a lot of work without any time
> passing. Unfortunately, this can result in OOM situations as the RCU
> core code will never be run.
>
> Work around that by kicking the RCU using rcu_sched_clock_irq. So
> behave to the RCU code as if a clock tick happened every syscall.
>
> Signed-off-by: Benjamin Berg <benjamin.berg at intel.com>
>
> ---
>
> This patch is on top of "um: fix time-travel syscall scheduling hack"
> ---
>  arch/um/kernel/skas/syscall.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c
> index b09e85279d2b..4b4ab8bf8a0c 100644
> --- a/arch/um/kernel/skas/syscall.c
> +++ b/arch/um/kernel/skas/syscall.c
> @@ -19,6 +19,21 @@ void handle_syscall(struct uml_pt_regs *r)
>         struct pt_regs *regs = container_of(r, struct pt_regs, regs);
>         int syscall;
>
> +       /*
> +        * This is a "bit" of a hack. But in time-travel mode userspace can do
> +        * a lot of work without any time passing. Unfortunately, this can
> +        * result in OOM situations as the RCU core code will never be run.
> +        *
> +        * Work around that by kicking the RCU using rcu_sched_clock_irq. So
> +        * behave to the RCU code as if a clock tick happened every syscall.
> +        */
> +       if (time_travel_mode == TT_MODE_INFCPU ||
> +           time_travel_mode == TT_MODE_EXTERNAL) {
> +               local_irq_disable();
> +               rcu_sched_clock_irq(1);
> +               local_irq_enable();
> +       }
> +

While I acknowledge that time-travel itself is a beautiful hack, I'd
like to keep the hacks
to keep it working minimal.
So, the problem here is that RCU callbacks never run and just pile up?

I wonder why such a situation does not happen in a nohz_full setup on
regular systems.

-- 
Thanks,
//richard



More information about the linux-um mailing list