All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Eduard Zingerman <eddyz87@gmail.com>,
	kernel-team@fb.com
Subject: [PATCH bpf-next v5 10/21] bpf: Refuse a private stack for a program with an exception cleanup table
Date: Tue, 22 Sep 2026 21:59:37 -0700	[thread overview]
Message-ID: <20260923045937.2419634-1-yonghong.song@linux.dev> (raw)
In-Reply-To: <20260923045846.2414643-1-yonghong.song@linux.dev>

A private stack is hard to support together with an exception cleanup
table on x86-64: a landing pad runs on the bpf_throw() walker's stack with
its frame's registers put back from a spill area, and carrying the private
stack's frame pointer through there as well would cost a register that
architecture cannot spare.

Force NO_PRIV_STACK in check_max_stack_depth(), where the choice is made,
and do it on every architecture for now rather than just x86-64. The
program still loads, but more than an optimization can be lost:
check_max_stack_depth_subprog() checks a PRIV_STACK_ADAPTIVE subprogram
against MAX_BPF_STACK on its own, and adds a NO_PRIV_STACK one to the
depth its callers have to fit in -- so a bpf2bpf chain deep enough to need
the private stack is now refused with "combined stack size of %d calls is
%d. Too large".

Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
---
 kernel/bpf/verifier.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7b74dd9b9f48..6462e9f2ffdc 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5602,6 +5602,17 @@ static int check_max_stack_depth(struct bpf_verifier_env *env)
 		}
 	}
 
+	/*
+	 * A pad rebuilds its frame from a spill area, and on x86-64 a private
+	 * stack's frame pointer lives in r9, which no spill area holds.
+	 * Refused on every arch rather than just that one. The subprograms
+	 * below are then checked against MAX_BPF_STACK together rather than
+	 * one at a time, so this can turn a program that would have loaded
+	 * with a private stack into one that is too deep.
+	 */
+	if (env->cleanup_info_cnt)
+		priv_stack_mode = NO_PRIV_STACK;
+
 	if (priv_stack_mode == PRIV_STACK_UNKNOWN)
 		priv_stack_mode = bpf_enable_priv_stack(env->prog);
 
-- 
2.53.0-Meta


  parent reply	other threads:[~2026-09-23  4:59 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23  4:58 [PATCH bpf-next v5 00/21] bpf: Run exception cleanup landing pads when bpf_throw() unwinds Yonghong Song
2026-09-23  4:58 ` [PATCH bpf-next v5 01/21] bpf: Pack bpf_insn_aux_data flags into bit fields Yonghong Song
2026-09-23  5:40   ` bot+bpf-ci
2026-09-23 19:16   ` Eduard Zingerman
2026-09-23  4:58 ` [PATCH bpf-next v5 02/21] bpf: Accept the compiler's exception cleanup table at program load Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 03/21] bpf: Add the bpf_unwind_resume() kfunc Yonghong Song
2026-09-23  6:13   ` Kumar Kartikeya Dwivedi
2026-09-23  4:59 ` [PATCH bpf-next v5 04/21] bpf: Add lookups for exception cleanup resumes and landing pads Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 05/21] bpf: Prepare for an exception cleanup table before the CFG walk Yonghong Song
2026-09-23  5:40   ` bot+bpf-ci
2026-09-23  4:59 ` [PATCH bpf-next v5 06/21] bpf: Make exception landing pads reachable in the CFG Yonghong Song
2026-09-23  5:51   ` bot+bpf-ci
2026-09-23 19:25   ` Eduard Zingerman
2026-09-23  4:59 ` [PATCH bpf-next v5 07/21] bpf: Explore the landing pads no call site reaches Yonghong Song
2026-09-23 16:26   ` Eduard Zingerman
2026-09-23 17:27     ` Yonghong Song
2026-09-23 18:06       ` Eduard Zingerman
2026-09-23 18:09         ` Yonghong Song
2026-09-23 21:28     ` Alexei Starovoitov
2026-09-23 22:19       ` Eduard Zingerman
2026-09-23 23:20         ` Alexei Starovoitov
2026-09-24  0:13           ` Kumar Kartikeya Dwivedi
2026-09-24  1:53             ` Alexei Starovoitov
2026-09-24  6:12               ` Kumar Kartikeya Dwivedi
2026-09-23 23:09       ` Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 08/21] bpf: Walk the exception unwind in the verifier Yonghong Song
2026-09-23 16:34   ` Eduard Zingerman
2026-09-23 18:01     ` Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 09/21] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch Yonghong Song
2026-09-23  4:59 ` Yonghong Song [this message]
2026-09-23  4:59 ` [PATCH bpf-next v5 11/21] bpf: Dispatch exception cleanup pads from bpf_throw() Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 12/21] bpf, x86: Dispatch exception cleanup pads at run time Yonghong Song
2026-09-23  6:45   ` Eduard Zingerman
2026-09-23 20:45     ` Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 13/21] bpf, arm64: " Yonghong Song
2026-09-23  4:59 ` [PATCH bpf-next v5 14/21] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc Yonghong Song
2026-09-23  8:36   ` Kumar Kartikeya Dwivedi
2026-09-23  5:00 ` [PATCH bpf-next v5 15/21] libbpf: Add cleanup_info to bpf_prog_load_opts Yonghong Song
2026-09-23  5:00 ` [PATCH bpf-next v5 16/21] libbpf: Collect .bpf_cleanup records and pass them to the kernel Yonghong Song
2026-09-23  5:52   ` Kumar Kartikeya Dwivedi
2026-09-23  5:00 ` [PATCH bpf-next v5 17/21] libbpf: Carry the exception cleanup table through the light skeleton Yonghong Song
2026-09-23  5:00 ` [PATCH bpf-next v5 18/21] libbpf: Let the static linker carry .bpf_cleanup relocations Yonghong Song
2026-09-23  5:40   ` bot+bpf-ci
2026-09-23  5:00 ` [PATCH bpf-next v5 19/21] selftests/bpf: Add an end-to-end .bpf_cleanup exception test Yonghong Song
2026-09-23  5:51   ` bot+bpf-ci
2026-09-23  5:00 ` [PATCH bpf-next v5 20/21] selftests/bpf: Cover the exception cleanup shapes the chain does not reach Yonghong Song
2026-09-23  5:51   ` bot+bpf-ci
2026-09-23  7:50   ` Eduard Zingerman
2026-09-23  5:00 ` [PATCH bpf-next v5 21/21] selftests/bpf: Load an exception cleanup program from a light skeleton Yonghong Song

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=20260923045937.2419634-1-yonghong.song@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@fb.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.