All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	kkd@meta.com, 	kernel-team@meta.com
Subject: Re: [PATCH bpf-next v1 1/2] bpf: Summarize sleepable global subprogs
Date: Fri, 28 Feb 2025 12:42:07 -0800	[thread overview]
Message-ID: <be5c35ce48592380e4edfabac2866bfc4f822cac.camel@gmail.com> (raw)
In-Reply-To: <20250228162858.1073529-2-memxor@gmail.com>

On Fri, 2025-02-28 at 08:28 -0800, Kumar Kartikeya Dwivedi wrote:
> The verifier currently does not permit global subprog calls when a lock
> is held, preemption is disabled, or when IRQs are disabled. This is
> because we don't know whether the global subprog calls sleepable
> functions or not.
> 
> In case of locks, there's an additional reason: functions called by the
> global subprog may hold additional locks etc. The verifier won't know
> while verifying the global subprog whether it was called in context
> where a spin lock is already held by the program.
> 
> Perform summarization of the sleepable nature of a global subprog just
> like changes_pkt_data and then allow calls to global subprogs for
> non-sleepable ones from atomic context.
> 
> While making this change, I noticed that RCU read sections had no
> protection against sleepable global subprog calls, include it in the
> checks and fix this while we're at it.
> 
> Care needs to be taken to not allow global subprog calls when regular
> bpf_spin_lock is held. When resilient spin locks is held, we want to
> potentially have this check relaxed, but not for now.
> 
> Tests are included in the next patch to handle all special conditions.
> 
> Fixes: 9bb00b2895cb ("bpf: Add kfunc bpf_rcu_read_lock/unlock()")
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---

I think this change also has to deal with freplace for sleepable
sub-programs, e.g. see verifier.c:bpf_check_attach_target(),
part dealing with `tgt_changes_pkt_data`.

Other than that the logic seems ok.

[...]


  reply	other threads:[~2025-02-28 20:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-28 16:28 [PATCH bpf-next v1 0/2] Global subprogs in RCU/{preempt,irq}-disabled sections Kumar Kartikeya Dwivedi
2025-02-28 16:28 ` [PATCH bpf-next v1 1/2] bpf: Summarize sleepable global subprogs Kumar Kartikeya Dwivedi
2025-02-28 20:42   ` Eduard Zingerman [this message]
2025-02-28 20:47     ` Kumar Kartikeya Dwivedi
2025-02-28 23:18   ` Andrii Nakryiko
2025-02-28 23:23     ` Eduard Zingerman
2025-02-28 23:34       ` Andrii Nakryiko
2025-02-28 23:57         ` Eduard Zingerman
2025-03-01  1:43           ` Kumar Kartikeya Dwivedi
2025-02-28 16:28 ` [PATCH bpf-next v1 2/2] selftests/bpf: Test sleepable global subprogs in atomic contexts Kumar Kartikeya Dwivedi
2025-02-28 21:21   ` Eduard Zingerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be5c35ce48592380e4edfabac2866bfc4f822cac.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.