From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 33ADBC79F82 for ; Fri, 4 Sep 2026 19:51:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=x1G9J4hfvrFwGfOijre8DcYvm34FubK2EZrXhUcbfCg=; b=DUt4KzeiRMHyUm AI61R6kzm0JbET3CvrK5A7Oyuv+iCX1qGOMW8IufKH0wDXg3A2wFRwtZLYp1FoEdIoYMgw8A3ZQGN S24LKSYBKWFbTLXLy68u0kqEOZuAUC/j83y0FHmTgquJ8Q11201Y0PwZ9WA4Q+2Y0/Xd8n0gqihzF OX4PIMbWNsNzEYPgMYw3PdKx+9P8ro39tL1F5nLQa5wTs9SKrUS7C2iThQ+czunp6wxi8LJngydWA SjwwHAVtG9ciNjKVZivF8LCR8okKZ2tD/lE6/ZLpKPKyuv1kGOF0rHjFYVaXh8jkGTCJ0YoQaIOoC Y/GREOtNBhHAWOsCjygw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x2Zwp-00000003D8C-359h; Fri, 04 Sep 2026 19:51:39 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x2Zwm-00000003D6t-43Ut for linux-riscv@lists.infradead.org; Fri, 04 Sep 2026 19:51:39 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-84f3ab8750cso1201421b3a.0 for ; Fri, 04 Sep 2026 12:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788551496; x=1789156296; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=bKfMAbI9WP00e34xfYRqukO9FWyuttxaiqoWfdsqtb0=; b=WOtBCDWLkr03s17jT2lraZJ/fgQBtZt0mPoQtos8MBm7+6qsaILhjixtE7+kKsBh1+ AdUdGB9//aC4CyGUQu3aQ4uwd/e4sy0ZoCGDe62axVz9ZOsUfwsDIR/qvRajZ0DG20uv wnkMldYiMDkuHE9XSbtgqAlHuMiEB/3KnhZfqTa84aqc4S6/exgcHE1wSMNJSgxOIC0v P8ho1KXoIDI8gmeQYuGv6xinCOIuFXcPHa6xyC3m/OtkzJ8KuO65hGR/1pqhQww21fA7 ZmLWWrBAjrJoKaIcLM1EHgzY3m2mviaAc9abXKakP6H9i1i5uhUwrKrpvX1Rd+etzLbU Gd1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788551496; x=1789156296; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=bKfMAbI9WP00e34xfYRqukO9FWyuttxaiqoWfdsqtb0=; b=FJHpLJuKmJkSfkhOl4Y07l9Lfr5tUeTLAeEFDDol0x0YAZXuXcobbwZyjI7xS/GWAk YIxSyH8pOrRfkcySmaTYczqGbC5Y5ba7l04mYZ10f1sW658s9mvxhyCWydjzRWYieUpD VQr/NHX112C9xtNFRPemZ18QeZhQJN5tDGryeAXFzdzITwnVG5Nwg+wqc9uDGHIF6H/o X1YiZGBuGbWiko4Sk0Ne79+XLXeYOhQ3BBLz4ZkNqoQJrA4CEFclN63HYS7UYOdANwoj FoykK3sE4pbtupw7wgJJtc8fhNkDckAaAkO8IcyNlcMWcMukpAKmIiUfBqvqMTEjQUOx Pe5g== X-Forwarded-Encrypted: i=1; AKwUvByOTKfwaJi8DjzVo6LcU485hkAh06MUBRex0k9awyxseJNCYtgPycierR/3mo9qwuy8gwXcykxE9IJqZA==@lists.infradead.org X-Gm-Message-State: AFuF++lFfUxx0yyET1ZPqNc/Pv0n28VC2VmsCRO6EpGeaXZ6+DOpfUpC rs0yuYxkiHGx/F5Ymp1oBNQQwm5UgRQ+q5f1XoThghA8iDUKHzKbQ/e7 X-Gm-Gg: AYBFou0kEfW7WFIqJyAIbspFHipb/RfjpDCifzNJ7w6sJ9r2kj+JsH/XHVc20YHKurC Bc5Zq6XeT3YwqbkbSAeim1kBHNURhy4KWOWsJaChqOwCGMxetQf8ibWUyg5Oe/gSCyAS3Z7MpfK /EpNuyMuwSwtqYGOQbnMXNmbBx6d959MvnjZY1LMoaD5fAXTANRAfrKODA+Nb5nZuwBh5QfVtle dhnypcchmJ8iiWmoxytNSal/+69OcO4h2ji/E12UjkOBMviXaxsv6Sd0gMhXKPh3hdc3QuUPVrJ T+begowxE9qtoJQhhHRvOheN0M0Qew+N4o+VuXDvtTjYszYsNBmShaoq/7JWg1RcCS0gW97Q7je T+p/zPhJxGCyYaFl5CLIt35XiqmeKrKUtW8zAHzONukhLUf2Mc7Q3Vdo2EEVFrp9ph/AJzxwz0U KYp1MGpCTAoXuZMcPcLzbHLz3MT/qRivF6i0vbHCZV3ljx2lW32i3IbjbACHS+vDF3qfcFWj3e8 P/JII1FwTsV2vKSF5QUTuLHjTVREKF04xgiOgnEdzMhHFsRR5eZExYf3AiCRIlANXu4QvIAlgyR eFk64u/7O8OH+fWEAx7qx4+VULVTnEH5gvu7+lQ0UJp1++mONtaklB/ZGJkg7bM26sBdrtS4xWM = X-Received: by 2002:a05:6a00:b94:b0:84e:2382:f4f0 with SMTP id d2e1a72fcca58-861660e2f8amr11334624b3a.4.1788551495503; Fri, 04 Sep 2026 12:51:35 -0700 (PDT) Received: from sid-dev-env.cgrhrlrrq2nuffriizdlnb1x4b.xx.internal.cloudapp.net ([4.155.54.158]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8615404876fsm1497684b3a.59.2026.09.04.12.51.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 12:51:35 -0700 (PDT) From: Siddharth Chintamaneni To: bpf@vger.kernel.org Cc: Siddharth Chintamaneni , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Anton Protopopov , Puranjay Mohan , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-riscv@lists.infradead.org, rlmenge@gmail.com, hargar@linux.microsoft.com, apais@microsoft.com Subject: [PATCH bpf-next v1 0/7] Fix timed may_goto with private stacks Date: Fri, 4 Sep 2026 19:51:25 +0000 Message-ID: <20260904195132.141068-1-sidchintamaneni@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260904_125137_026751_C576FBF4 X-CRM114-Status: GOOD ( 11.26 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Jeremy reported a bug[1] while executing a BPF program containing timed_may_goto instructions with private stacks. timed_may_goto[2] is a runtime safety mechanism that allows BPF programs to execute longer loops[3]. The BPF verifier replaces each may_goto instruction with a loop counter initialized to 0xffff and a timestamp check[4] that terminates the loop after 250 ms. Private stacks[5] allow BPF programs to use per-CPU memory instead of consuming more of the native kernel stack when BPF programs are deeply nested. To make timed may_goto work, the BPF program reserves 16 bytes of stack space. The first 8 bytes store the loop counter and the next 8 bytes store the timestamp. After the loop counter is exhausted, arch_bpf_timed_may_goto() is called. On x86, it adds the counter's stack offset to RBP to obtain a pointer to the counter and timestamp[6]. This works when the BPF program uses the normal stack because RBP is also the BPF frame pointer. When a private stack is used, the x86 JIT uses R9 as the BPF frame pointer. The verifier-generated loads and stores therefore access the counter and timestamp through R9. However, arch_bpf_timed_may_goto() still adds the offset to RBP and accesses an unrelated location in the native JIT stack frame. This is the mismatch Jeremy reported. Fix the mismatch by resolving the address in the generated BPF instructions: BPF_REG_AX = BPF_REG_FP BPF_REG_AX += stack_offset The JIT can then select the correct BPF frame pointer before calling arch_bpf_timed_may_goto(). The function receives the resolved pointer instead of reconstructing it from RBP. The LoongArch timed may_goto implementation is currently queued through the loongarch-next tree[7], while its selftests were merged separately through the bpf-next tree[8]. This series is based on bpf-next and therefore does not include the LoongArch trampoline update. [1] https://lore.kernel.org/all/20260824213158.3755932-2-Jeremy.Jean@oss.cyber.gouv.fr/ [2] https://lore.kernel.org/all/20250304003239.2390751-1-memxor@gmail.com/ [3] https://elixir.bootlin.com/linux/v7.2.2/source/tools/testing/selftests/bpf/libarena/include/bpf_may_goto.h#L8 [4] https://elixir.bootlin.com/linux/v7.2.2/source/kernel/bpf/core.c#L3407 [5] https://lore.kernel.org/bpf/20260417034658.2625353-1-yonghong.song@linux.dev/ [6] https://elixir.bootlin.com/linux/v7.2.2/source/arch/x86/net/bpf_timed_may_goto.S#L18 [7] https://lore.kernel.org/loongarch/20260804153938.16129-3-dongtai.guo@linux.dev/ [8] https://lore.kernel.org/bpf/20260813070906.5164-1-yangtiezhu@loongson.cn/ Siddharth Chintamaneni (7): bpf: Fix timed may_goto stack pointer for private stacks bpf, x86: Use resolved pointer for timed may_goto bpf, arm64: Use resolved pointer for timed may_goto bpf, powerpc64: Use resolved pointer for timed may_goto bpf, riscv: Use resolved pointer for timed may_goto bpf, s390: Use resolved pointer for timed may_goto selftests/bpf: Test timed may_goto with private stacks arch/arm64/net/bpf_timed_may_goto.S | 12 ++------ arch/powerpc/net/bpf_timed_may_goto.S | 8 ++--- arch/riscv/net/bpf_timed_may_goto.S | 13 ++++---- arch/s390/net/bpf_jit_comp.c | 6 ++-- arch/s390/net/bpf_timed_may_goto.S | 8 ++--- arch/x86/net/bpf_timed_may_goto.S | 6 ---- kernel/bpf/fixups.c | 19 ++++++------ .../bpf/progs/verifier_bpf_fastcall.c | 30 ++++++++++--------- .../selftests/bpf/progs/verifier_may_goto_1.c | 17 ++++++----- .../bpf/progs/verifier_private_stack.c | 19 ++++++++++++ 10 files changed, 75 insertions(+), 63 deletions(-) base-commit: d761934c9483ecde93fe99d8705282f716dfee50 -- 2.43.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D20E6165F1A for ; Fri, 4 Sep 2026 19:51:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788551499; cv=none; b=q9ivJuPOIXgBsM/vxf/gQeD8cS4AA2O0IMUrpnLVLrtkU7spm/2F3+vjjlzFlDUd2DK8ibxvZ1DVng0Q6ci9RAbGS1kqHlgVTBZJTYItvghq8v2raZ47o4kzQTlORz8CySDLwcc0luxWf3QLobhkQFufMrOACmsVtTWWcfURoxI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788551499; c=relaxed/simple; bh=+uN4T6fpz76fkQR6WHSLomy4qLe4nZX50dqq9h8xTVc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=a1+7Hk7DbPu6NWI3SP4VYm8WjZjkD8XbbLqYnsAZDPCWMoxPxWkZi2EEAPRHpfT5fNEpTLlKfqbmNFHgaZBXBndt3iDtJkFTrZUiTYH4FGsOA5OEvP/VravYieUjtJfJccUd8cOA8/6or1NMNt5MnVnDaeRfACMESzUCS9qP9iU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Do6Mj8+q; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Do6Mj8+q" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-862815e2683so572522b3a.2 for ; Fri, 04 Sep 2026 12:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788551496; x=1789156296; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=bKfMAbI9WP00e34xfYRqukO9FWyuttxaiqoWfdsqtb0=; b=Do6Mj8+qWLOOjAK58g5xLEuYtLfjG/GzM9iOdxxTnHyfomlcbwqR6RurY/ZaPBg1QS BJG08KnIIBS5yWblkDXIXo1krX/YkBifbwbOsuDFhILIGq62WxChFzeHiDD6Hvr4YIau pnb068BVdVie7i8e3hjtdEwcDhR850TFgQcst5b8MLlBfgBlrEtQ9yuRkERH+ttRj9zv GtNJYoFwSi7jheYK041DF+urPSnypVmzInC7GxyERA9B0yhgKgrZkmWrHVjXsCrYIvs3 9dg+bcyHFJazBbIOHoZxLN06gAROhaBf5iccY8wbSS9XDnKEp4UzppNFD4Rv4v67S3tb /4eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788551496; x=1789156296; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=bKfMAbI9WP00e34xfYRqukO9FWyuttxaiqoWfdsqtb0=; b=E91PhwajN6T8k0txNvEWbDBmVl6TpAsF5o1EALjh/sqNnW7Su38p4kk2ftCgNC3Yf4 Qz13AucrZGf6k9fRFI1xyJ+HWJfgO2G6ISs2FqG3FDrQORkkW5tIzrmwAAFGxsyP8Fv4 XlOH506xRKUghhUOHmpRkAXqufyEPCnKkBap1fYQLnL8nzob9fjshd//ot/fGtYNjXag VuGnzEk/uBX2MouUJUyMlLO0JRX4EzakMoeoxm3ydOyFYilT3AzZHXQt+CtTC94NCYpB KEYN0Tt8Q5uUBzUQmzKIzCjh3ppvR2PSLkMiMWxZo1UP/cgdkoJaDcqziXtc6fEMEq2+ 3/QA== X-Forwarded-Encrypted: i=1; AKwUvByUXErJ7xAsg9/q2z7zR840n5bZ2pSLY3p/XhE3TD4I6tbgRHQh1XPHb3WsPhL91SB2yRKA0dgH3VNd@vger.kernel.org X-Gm-Message-State: AFuF++k4Ky3k7zPmBdSY0O5wWj166bt/LQ0ihUkIKlBj7y8kT+P390LQ jbG1j7Ak41LxEqzXRz6J1jI040zn8TUbRc00EdIIRUfeMerhnzYG0HQi X-Gm-Gg: AYBFou3MnARiV5uLDFzvPYVvA+18wvxzmp6JeIwLwg3eLSdwqOSz4iCKth9A5nnQZSJ P2ULdP1AY5w2gz8svpltaGBZdQoKkhe486/h/e/30NgcLeovRNRZwTaFiE3tt/CFOkBL10DCfN4 Wi3J1Jx+8vz8YrT5GiYPIZnbpAvUegE3BgMChzb9ypayY2KRZKa5vrRGfR+zxgNhFf4ZGhfb82D Sg/8lImvkKWK+rHBbR2aiKfWbL1EKpfoppc8dBcXKjsTpSq0cRMatrrfuyS9JWErOej/KbnshLw SXuNxV6H2lIN0fg89+jEUVAlVBszdNJRhxtfmfuGdXIcc1H24WvlI/zW/xbE8khLWYms6Zq8UuP J9D5936Izj5KPnknNvduOT1ibKIA6rJSMEpims1itHDZK1JUI9vbYgTJLjlZs52SHRMY5z6BO+/ Uv/u3P1xFKcqMT3To+DwluQFH/e1i4uWai6JWxQlRUazi/Idp9sFvvoYE3r2zJuJxXPYOPHCFDw iKDTVxBYwQ4QZHLFzyDmOxT1ePRUhLPhtlZs0n9G5dgQxPSboUvb94EK5DCSmfiZUcmzpW9iPhZ 838pZUTfGQRFwYoZBYYmP73+yFKzP7y1zoR6dWkhfrmJd7/k4WNU+sQxr481Ku2AomVMvD5m1as = X-Received: by 2002:a05:6a00:b94:b0:84e:2382:f4f0 with SMTP id d2e1a72fcca58-861660e2f8amr11334624b3a.4.1788551495503; Fri, 04 Sep 2026 12:51:35 -0700 (PDT) Received: from sid-dev-env.cgrhrlrrq2nuffriizdlnb1x4b.xx.internal.cloudapp.net ([4.155.54.158]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8615404876fsm1497684b3a.59.2026.09.04.12.51.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 12:51:35 -0700 (PDT) From: Siddharth Chintamaneni To: bpf@vger.kernel.org Cc: Siddharth Chintamaneni , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Anton Protopopov , Puranjay Mohan , linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-riscv@lists.infradead.org, rlmenge@gmail.com, hargar@linux.microsoft.com, apais@microsoft.com Subject: [PATCH bpf-next v1 0/7] Fix timed may_goto with private stacks Date: Fri, 4 Sep 2026 19:51:25 +0000 Message-ID: <20260904195132.141068-1-sidchintamaneni@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Jeremy reported a bug[1] while executing a BPF program containing timed_may_goto instructions with private stacks. timed_may_goto[2] is a runtime safety mechanism that allows BPF programs to execute longer loops[3]. The BPF verifier replaces each may_goto instruction with a loop counter initialized to 0xffff and a timestamp check[4] that terminates the loop after 250 ms. Private stacks[5] allow BPF programs to use per-CPU memory instead of consuming more of the native kernel stack when BPF programs are deeply nested. To make timed may_goto work, the BPF program reserves 16 bytes of stack space. The first 8 bytes store the loop counter and the next 8 bytes store the timestamp. After the loop counter is exhausted, arch_bpf_timed_may_goto() is called. On x86, it adds the counter's stack offset to RBP to obtain a pointer to the counter and timestamp[6]. This works when the BPF program uses the normal stack because RBP is also the BPF frame pointer. When a private stack is used, the x86 JIT uses R9 as the BPF frame pointer. The verifier-generated loads and stores therefore access the counter and timestamp through R9. However, arch_bpf_timed_may_goto() still adds the offset to RBP and accesses an unrelated location in the native JIT stack frame. This is the mismatch Jeremy reported. Fix the mismatch by resolving the address in the generated BPF instructions: BPF_REG_AX = BPF_REG_FP BPF_REG_AX += stack_offset The JIT can then select the correct BPF frame pointer before calling arch_bpf_timed_may_goto(). The function receives the resolved pointer instead of reconstructing it from RBP. The LoongArch timed may_goto implementation is currently queued through the loongarch-next tree[7], while its selftests were merged separately through the bpf-next tree[8]. This series is based on bpf-next and therefore does not include the LoongArch trampoline update. [1] https://lore.kernel.org/all/20260824213158.3755932-2-Jeremy.Jean@oss.cyber.gouv.fr/ [2] https://lore.kernel.org/all/20250304003239.2390751-1-memxor@gmail.com/ [3] https://elixir.bootlin.com/linux/v7.2.2/source/tools/testing/selftests/bpf/libarena/include/bpf_may_goto.h#L8 [4] https://elixir.bootlin.com/linux/v7.2.2/source/kernel/bpf/core.c#L3407 [5] https://lore.kernel.org/bpf/20260417034658.2625353-1-yonghong.song@linux.dev/ [6] https://elixir.bootlin.com/linux/v7.2.2/source/arch/x86/net/bpf_timed_may_goto.S#L18 [7] https://lore.kernel.org/loongarch/20260804153938.16129-3-dongtai.guo@linux.dev/ [8] https://lore.kernel.org/bpf/20260813070906.5164-1-yangtiezhu@loongson.cn/ Siddharth Chintamaneni (7): bpf: Fix timed may_goto stack pointer for private stacks bpf, x86: Use resolved pointer for timed may_goto bpf, arm64: Use resolved pointer for timed may_goto bpf, powerpc64: Use resolved pointer for timed may_goto bpf, riscv: Use resolved pointer for timed may_goto bpf, s390: Use resolved pointer for timed may_goto selftests/bpf: Test timed may_goto with private stacks arch/arm64/net/bpf_timed_may_goto.S | 12 ++------ arch/powerpc/net/bpf_timed_may_goto.S | 8 ++--- arch/riscv/net/bpf_timed_may_goto.S | 13 ++++---- arch/s390/net/bpf_jit_comp.c | 6 ++-- arch/s390/net/bpf_timed_may_goto.S | 8 ++--- arch/x86/net/bpf_timed_may_goto.S | 6 ---- kernel/bpf/fixups.c | 19 ++++++------ .../bpf/progs/verifier_bpf_fastcall.c | 30 ++++++++++--------- .../selftests/bpf/progs/verifier_may_goto_1.c | 17 ++++++----- .../bpf/progs/verifier_private_stack.c | 19 ++++++++++++ 10 files changed, 75 insertions(+), 63 deletions(-) base-commit: d761934c9483ecde93fe99d8705282f716dfee50 -- 2.43.0