From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADE401EB195 for ; Sat, 20 Dec 2025 07:34:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766216071; cv=none; b=Jg+jT2KaLFu2g0K8bvGS+q6CWIUtjTT1IPUaGs4dsOTrukdHFZ0vxoNePjA/qFQvWmJW48YStJr/epzlaQ0lms1bhug1KESqv8owxruITGfB1Zb0tT5rkGlcn2qBQrZMshD18/01JLBukr8XhwuBzfUTRjTB5ll58eWomlEgHMg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766216071; c=relaxed/simple; bh=XUzXaXgAsgoDGDRQtOHCa3FfJDiAccBSyNkpwKM3LNY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tHeF3Jk50pXa4UZHydrN/hP9YsgFgNMqlt4l7nTMbMcRLXSzPbZ5NO6Rll9S5Au4CzE+S88/suL53uIzeZRaVCE/QhkECBNGrCzMyuVT71DISrpEoN3PAFaZTW/vOoODxnFX4c0imPjad7K6COZvBhwoZPI9DGpss4aNPIJRRYI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=HeyY+W2S; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="HeyY+W2S" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1766216061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S91jpqXqsg0Jhi5+sYGwbVyxcd6hPUpwSC+NwxrECyc=; b=HeyY+W2S4IlGyi42CgeG9vVBzjsFsJ67uIQQZ7TAghIE8ud81U6CuHRBCmHAPcCWX78aRA a2YBH5bXwtw83cTHp/1M/5tCVBn1cqLNWzYN6JO3eKrKIBa9aF3poFQ+Hu+zbB0qyYdphy K0vH8DouyMMx4ZNMWBPTQWyv+ML2t4M= From: Menglong Dong To: Menglong Dong , schwab@linux-m68k.org, Pu Lehui , andrii@kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org, bjorn@kernel.org, puranjay@kernel.org, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, bpf@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf v2] riscv, bpf: fix incorrect usage of BPF_TRAMP_F_ORIG_STACK Date: Sat, 20 Dec 2025 15:33:58 +0800 Message-ID: <8619181.T7Z3S40VBb@7950hx> In-Reply-To: <33977244-1266-4590-af38-e3be3e46d7f4@huawei.com> References: <20251219142948.204312-1-dongml2@chinatelecom.cn> <33977244-1266-4590-af38-e3be3e46d7f4@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Migadu-Flow: FLOW_OUT On 2025/12/20 10:59, Pu Lehui wrote: > > On 2025/12/19 22:29, Menglong Dong wrote: > > The usage of BPF_TRAMP_F_ORIG_STACK in __arch_prepare_bpf_trampoline() is > > wrong, and it should be BPF_TRAMP_F_CALL_ORIG, which caused crash as > > Andreas reported: > > > > Insufficient stack space to handle exception! > > Task stack: [0xff20000000010000..0xff20000000014000] > > Overflow stack: [0xff600000ffdad070..0xff600000ffdae070] > > CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary) > > Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025 > > epc : copy_from_kernel_nofault+0xa/0x198 > > ra : bpf_probe_read_kernel+0x20/0x60 > > epc : ffffffff802b732a ra : ffffffff801e6070 sp : ff2000000000ffe0 > > gp : ffffffff82262ed0 tp : 0000000000000000 t0 : ffffffff80022320 > > t1 : ffffffff801e6056 t2 : 0000000000000000 s0 : ff20000000010040 > > s1 : 0000000000000008 a0 : ff20000000010050 a1 : ff60000083b3d320 > > a2 : 0000000000000008 a3 : 0000000000000097 a4 : 0000000000000000 > > a5 : 0000000000000000 a6 : 0000000000000021 a7 : 0000000000000003 > > s2 : ff20000000010050 s3 : ff6000008459fc18 s4 : ff60000083b3d340 > > s5 : ff20000000010060 s6 : 0000000000000000 s7 : ff20000000013aa8 > > s8 : 0000000000000000 s9 : 0000000000008000 s10: 000000000058dcb0 > > s11: 000000000058dca7 t3 : 000000006925116d t4 : ff6000008090f026 > > t5 : 00007fff9b0cbaa8 t6 : 0000000000000016 > > status: 0000000200000120 badaddr: 0000000000000000 cause: 8000000000000005 > > Kernel panic - not syncing: Kernel stack overflow > > CPU: 1 UID: 0 PID: 1 Comm: systemd Not tainted 6.18.0-rc5+ #15 PREEMPT(voluntary) > > Hardware name: riscv-virtio qemu/qemu, BIOS 2025.10 10/01/2025 > > Call Trace: > > [] dump_backtrace+0x28/0x38 > > [] show_stack+0x3a/0x50 > > [] dump_stack_lvl+0x56/0x80 > > [] dump_stack+0x18/0x22 > > [] vpanic+0xf6/0x328 > > [] panic+0x3e/0x40 > > [] handle_bad_stack+0x98/0xa0 > > [] bpf_probe_read_kernel+0x20/0x60 > > > > Just fix it. > > > > Fixes: 47c9214dcbea ("bpf: fix the usage of BPF_TRAMP_F_SKIP_FRAME") > > Reported-by: Andreas Schwab > > Closes: https://lore.kernel.org/bpf/874ipnkfvt.fsf@igel.home/ > > Signed-off-by: Menglong Dong > > --- > > v2: > > - merge the code > > --- > > arch/riscv/net/bpf_jit_comp64.c | 6 ++---- > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c > > index 5f9457e910e8..37888abee70c 100644 > > --- a/arch/riscv/net/bpf_jit_comp64.c > > +++ b/arch/riscv/net/bpf_jit_comp64.c > > @@ -1133,10 +1133,6 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, > > > > store_args(nr_arg_slots, args_off, ctx); > > > > - /* skip to actual body of traced function */ > > - if (flags & BPF_TRAMP_F_ORIG_STACK) > > Oh, how did this weird flags get in here... It's my fault. I wanted to use BPF_TRAMP_F_CALL_ORIG here, and a copy-paste mistake happen. They look a little similar :( > > > - orig_call += RV_FENTRY_NINSNS * 4; > > - > > if (flags & BPF_TRAMP_F_CALL_ORIG) { > > emit_imm(RV_REG_A0, ctx->insns ? (const s64)im : RV_MAX_COUNT_IMM, ctx); > > ret = emit_call((const u64)__bpf_tramp_enter, true, ctx); > > @@ -1171,6 +1167,8 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, > > } > > > > if (flags & BPF_TRAMP_F_CALL_ORIG) { > > + /* skip to actual body of traced function */ > > + orig_call += RV_FENTRY_NINSNS * 4; > > > LGTM, let's revert it. > > Reviewed-by: Pu Lehui > > > restore_args(min_t(int, nr_arg_slots, RV_MAX_REG_ARGS), args_off, ctx); > > restore_stack_args(nr_arg_slots - RV_MAX_REG_ARGS, args_off, stk_arg_off, ctx); > > ret = emit_call((const u64)orig_call, true, ctx); Andreas suggested that we remove the variable "orig_call" and use "func_addr + RV_FENTRY_NINSNS * 4" directly here. But I saw the V2 is already applied. Hmm...I think it doesn't matter. Thanks! Menglong Dong > >