[PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Sergey Senozhatsky]

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@chromium.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);
+}
+
 __bpf_kfunc_end_defs();
 
 BTF_KFUNCS_START(generic_btf_ids)
@@ -3388,6 +3394,7 @@ BTF_ID_FLAGS(func, bpf_iter_kmem_cache_next, KF_ITER_NEXT | KF_RET_NULL | KF_SLE
 BTF_ID_FLAGS(func, bpf_iter_kmem_cache_destroy, KF_ITER_DESTROY | KF_SLEEPABLE)
 BTF_ID_FLAGS(func, bpf_local_irq_save)
 BTF_ID_FLAGS(func, bpf_local_irq_restore)
+BTF_ID_FLAGS(func, bpf_msleep_interruptible, KF_SLEEPABLE)
 BTF_KFUNCS_END(common_btf_ids)
 
 static const struct btf_kfunc_id_set common_kfunc_set = {
-- 
2.49.0.1101.gccaa498523-goog

Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Ferenc Fejes]

Hi,

On Thu, 2025-05-15 at 15:47 +0900, Sergey Senozhatsky 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@chromium.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);

Perhaps exposing fsleep instead of msleep? fsleep might fallback to msleep if no
better mechanism exists or if the sleep duration is >1000us.

> +}
> +
>  __bpf_kfunc_end_defs();
>  
>  BTF_KFUNCS_START(generic_btf_ids)
> @@ -3388,6 +3394,7 @@ BTF_ID_FLAGS(func, bpf_iter_kmem_cache_next,
> KF_ITER_NEXT | KF_RET_NULL | KF_SLE
>  BTF_ID_FLAGS(func, bpf_iter_kmem_cache_destroy, KF_ITER_DESTROY |
> KF_SLEEPABLE)
>  BTF_ID_FLAGS(func, bpf_local_irq_save)
>  BTF_ID_FLAGS(func, bpf_local_irq_restore)
> +BTF_ID_FLAGS(func, bpf_msleep_interruptible, KF_SLEEPABLE)
>  BTF_KFUNCS_END(common_btf_ids)
>  
>  static const struct btf_kfunc_id_set common_kfunc_set = {

Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Sergey Senozhatsky]

On (25/05/15 10:59), Ferenc Fejes wrote:
> > +__bpf_kfunc unsigned long bpf_msleep_interruptible(unsigned int msecs)
> > +{
> > +	return msleep_interruptible(msecs);
> 
> Perhaps exposing fsleep instead of msleep? fsleep might fallback to msleep if no
> better mechanism exists or if the sleep duration is >1000us.

I like the TASK_INTERRUPTIBLE semantics of msleep_interruptible().

Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Andrii Nakryiko]

On Wed, May 14, 2025 at 11:48 PM Sergey Senozhatsky
<senozhatsky@chromium.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@chromium.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?

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.

pw-bot: cr

>  __bpf_kfunc_end_defs();
>
>  BTF_KFUNCS_START(generic_btf_ids)
> @@ -3388,6 +3394,7 @@ BTF_ID_FLAGS(func, bpf_iter_kmem_cache_next, KF_ITER_NEXT | KF_RET_NULL | KF_SLE
>  BTF_ID_FLAGS(func, bpf_iter_kmem_cache_destroy, KF_ITER_DESTROY | KF_SLEEPABLE)
>  BTF_ID_FLAGS(func, bpf_local_irq_save)
>  BTF_ID_FLAGS(func, bpf_local_irq_restore)
> +BTF_ID_FLAGS(func, bpf_msleep_interruptible, KF_SLEEPABLE)
>  BTF_KFUNCS_END(common_btf_ids)
>
>  static const struct btf_kfunc_id_set common_kfunc_set = {
> --
> 2.49.0.1101.gccaa498523-goog
>

Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Sergey Senozhatsky]

On (25/05/20 16:26), Andrii Nakryiko wrote:
> On Wed, May 14, 2025 at 11:48 PM Sergey Senozhatsky
> <senozhatsky@chromium.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@chromium.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?

Re: [PATCHv2] bpf: add bpf_msleep_interruptible() kfunc

[Andrii Nakryiko]

On Fri, May 23, 2025 at 12:23 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> On (25/05/20 16:26), Andrii Nakryiko wrote:
> > On Wed, May 14, 2025 at 11:48 PM Sergey Senozhatsky
> > <senozhatsky@chromium.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@chromium.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?

What we call "sleepable BPF" is really "faultable BPF", meaning we
only allow the kernel to handle page faults to bring data into
physical memory. There is no real sleeping (though userfaultfd is its
own set of problems when it comes to page fault predictability). So we
consider this fault delay to be bounded. With msleep() that
boundedness is explicitly abandoned.