linux-kernel - Re: [PATCHv2] bpf: add bpf_msleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <z4gvqyk3ktqhd4wmi7ju3qw67c56brf5klxcer3vqmp3v6sujn@2xq7j3ji4kic>
Date: Fri, 23 May 2025 16:23:25 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	John Fastabend <john.fastabend@...il.com>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Matt Bobrowski <mattbobrowski@...gle.com>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

On (25/05/20 16:26), Andrii Nakryiko wrote:
> On Wed, May 14, 2025 at 11:48 PM Sergey Senozhatsky
> <senozhatsky@...omium.org> wrote:
> >
> > bpf_msleep_interruptible() puts a calling context into an
> > interruptible sleep.  This function is expected to be used
> > for testing only (perhaps in conjunction with fault-injection)
> > to simulate various execution delays or timeouts.
> >
> > Signed-off-by: Sergey Senozhatsky <senozhatsky@...omium.org>
> > ---
> >
> > v2:
> > -- switched to kfunc (Matt)
> >
> >  kernel/bpf/helpers.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index fed53da75025..a7404ab3b0b8 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -24,6 +24,7 @@
> >  #include <linux/bpf_mem_alloc.h>
> >  #include <linux/kasan.h>
> >  #include <linux/bpf_verifier.h>
> > +#include <linux/delay.h>
> >
> >  #include "../../lib/kstrtox.h"
> >
> > @@ -3283,6 +3284,11 @@ __bpf_kfunc void bpf_local_irq_restore(unsigned long *flags__irq_flag)
> >         local_irq_restore(*flags__irq_flag);
> >  }
> >
> > +__bpf_kfunc unsigned long bpf_msleep_interruptible(unsigned int msecs)
> > +{
> > +       return msleep_interruptible(msecs);
> > +}
> > +
> 
> What happened to the trying out custom kernel module for
> fuzzing/testing use case you have?

Oh, my bad.  I think it wasn't clear to me that this was the final
conclusion, it looked to me that the conversation ended up with a
number of open questions.

> I'll repeat my concerns. BPF maps and progs are all interdependent
> between each other by global RCU Tasks Trace "domain". Delay one RCU
> tasks trace grace period through the use of msleep() will delay
> everything BPF-related in the entire kernel.
> 
> Until we have some way to give some of BPF programs and its isolated
> BPF maps its own RCU domain, I don't think we should allow arbitrary
> sleeps inside BPF programs.

I see.  How are sleepable BPF programs operate wrt RCU currently?