[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzYTiPuOUbQgkNvT2haAupeep79q0pVu=fcD5fEgnAjR_A@mail.gmail.com>
Date: Tue, 20 May 2025 16:26:55 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: 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 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?
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
>
Powered by blists - more mailing lists