From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 97E3A366575 for ; Wed, 1 Jul 2026 18:47:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782931655; cv=none; b=JYC/TBLXH7BPdctd+Ne/peMZkDwgJXFWT5qUQIu3J8qBkS/HNRag2qvwWyXNdNgH+WLU45h4ARoTQt8Gu/McSoOK1dBVCUMZBYbqU78wT/1vUWJ5VQgjaMEF3uE1ZO3iUN7gxXxBFe5NdyCHJCsh36DuBMmD7ncIjI73kKKVuqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782931655; c=relaxed/simple; bh=UMZ/oHufdmLrRebJhJdd4z9UveNzoktn4s6GK0qVg9Q=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=E8RfsIvv++gAGV6m9bi1iXxjgfN6qNeMY2v3KcYuFQrVC1ZQxUFl3Vm7BEEcZbl9TZqadyKk3oSzIJ2SetUNrzHxoVQDH8SKu0p7M+jZeT4Sz8Zweiuk77dmcf11MDksBwgTMrSPTCCkzQpBbkQEdQGrULCvKBGT8FS+QgPX894= 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=DQgLZEaz; arc=none smtp.client-ip=209.85.210.51 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="DQgLZEaz" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7e9f1f24cbcso742981a34.0 for ; Wed, 01 Jul 2026 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782931652; x=1783536452; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lTi92KcO4t4fC4vzqRv/t15HFT0DQF/tdlE/UMVxiuQ=; b=DQgLZEazr0mccZDrCefhzMX27C6s+NaL/n4WJoSQI9JspxndrjwG5PgNvqCkFMTLUd WSGbXgL/OcPpHCBcUgeUD9Slv1EJdvypcFE09QKvxEQIV4f/WVvJY3p8LEItwlyab7IK U0U0u/wd3Iw5Byl4FqTPHtqDu80cUkcoVnm4U+8O0w7FrriUJuyuoPG6YcLWGOaOHBTO 5mFEmaGHMkN9twoEh4Q6/NPz75EKSAuPJ0WpN090KIrK4oyJrEH2OYiEsFxGDvUkjnqh SPNn7O7IQ8VzMK43KAF7VwGsblY+vCO5DE1cKuvtKVwYooqIgpuTBt8sq9mCSgSyo2ib LVxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782931652; x=1783536452; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lTi92KcO4t4fC4vzqRv/t15HFT0DQF/tdlE/UMVxiuQ=; b=Yl5I4VEzaCj8f/LlZGZaHyiL4UHeVkn+2nqb3I4itphn7DGe377LsWKy7Wtxh+sark NfDXftkWGy4R0tnpULOwGsEr+fxASEvTiK46PYhgtiD40w3gkzvZRwQ6cRBVZ/czG2jh 23WjEAWQ8KPd+fq3JWaZ3dMvThZ/JIoB14EvZH0MsaSavyM1khCfeRuRUA1W/Vzj5ZN5 9tCQ9EHNNTG4iaZBxEgBY5iy+U+ETeBLBiG63Fbb/OxNWrdr2DBGHPiuVQgwUf2u64VC 9GjouTQREwhddHtvBET9t96/xHzv0Mw8t6D2RUumAKRDO8iadK//952FLxcaZSSSgNDa fKSg== X-Forwarded-Encrypted: i=1; AFNElJ/XNU/vTk1fwXCmMi0ilqURr2Tu+Do5+NBPgsg5nN/F9Pqkqy417wNdlZl7ngtfbvklI0s5jVtxurKJfDENHz0=@vger.kernel.org X-Gm-Message-State: AOJu0YxPSrpIBw3giehQI/BK+3leHKhWqezIVKXp9W0euacCBQ3VprTw J8T0ULb6FYEXFJKzettZvOhnS2o8il6biFaSK3eGxZwW+hSN4RlxRUW6 X-Gm-Gg: AfdE7clZjx/7tFqp3ktPHsgl7g1ugRmP5JubHgHypuKr/IMV51N8IzbOcHEWrdN0h4v nj3QwOMPBMHFx0Or9q4++SPNz5nfqnRcUnDMu66dGLVpdNcB/do3nyH9e5qMmUmlRQYKtLevwdQ rnSvPOOngrNVP1RpV5pY60LwBGeuKHp2aN1H1Y9uXj4UT7TGWWdhZXxHkOgeN2n1c7otWtx83IE 9UJDKsqzGsPfato01yCXxeJkf6InQL5ZEqkMZ5wVmG9ZS69OTt9YzCR1s1rTUbMkDJGgISSjS7j OtU8O9j5M3WPjKwJLskAvB9hwbnszlOrN5H6RtQmjjiJERQRVW4VQN2HPEaMjkanu5U5eHhx0BH cQSz9ApDfKm3qJKltD6X8ipntfTgydAsC+0d39oUGovNC4jnUz2te5XpLSMtPqdEMYLvvrEpil/ AwM/s+rocXASobenFyLqomQELCN2WesJTs4AuZrgK/q0W3JTaF4jG0Wl8XLmuI0ie/zjPx7P6uF jXPIw== X-Received: by 2002:a05:6830:1d63:b0:7e9:e9f3:266c with SMTP id 46e09a7af769-7e9f5f28f4cmr3112378a34.14.1782931652500; Wed, 01 Jul 2026 11:47:32 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:e::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7eb544a109fsm696811a34.14.2026.07.01.11.47.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 11:47:31 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 01 Jul 2026 11:47:30 -0700 Message-Id: Cc: "Leon Hwang" , "KaFai Wan" , , "Alexei Starovoitov" , "Daniel Borkmann" , "John Fastabend" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "Andrew Morton" , "Shuah Khan" , "Puranjay Mohan" , "Anton Protopopov" , , Subject: Re: [RFC PATCH bpf 1/6] bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn From: "Alexei Starovoitov" To: "Tiezhu Yang" , "Leon Huang Fu" X-Mailer: aerc References: <20260626154330.33619-1-leon.hwang@linux.dev> <20260626154330.33619-2-leon.hwang@linux.dev> <1c07a34f-b050-a281-6a7b-542a9bfa30b3@loongson.cn> <7438f087-7fb4-4991-a095-1d24d6d09895@loongson.cn> <20260701080524.194326-1-leon.huangfu@shopee.com> In-Reply-To: On Wed Jul 1, 2026 at 2:07 AM PDT, Tiezhu Yang wrote: > On 2026/7/1 =E4=B8=8B=E5=8D=884:04, Leon Huang Fu wrote: >> On Wed, 1 Jul 2026 15:29:28 +0800, Tiezhu Yang = wrote: >>> On 2026/7/1 =C3=A4=C2=B8=E2=80=B9=C3=A5=C2=8D=CB=863:02, Leon Hwang wro= te: >>>> On 1/7/26 14:49, Tiezhu Yang wrote: >>>> [...] >>>>>> >>>>>> It is a real issue. >>>>>> >>>>>> Instead of fixing up helper calls, it seems better to prevent >>>>>> interpreter fallback if the prog has any JIT-inlineable helper call. >>>>> >>>>> Hi Alexei and Leon, >>>>> >>>>> What about the following: (not tested yet, if it is good, I can test = it) >>>>> >>>>> [...] >>>>> >>>>> If you are OK with the above changes, I will test it again and send >>>>> a new version later. >>>>> >>>> >>>> If you don't mind, I think I can disallow the interpreter fallback by >>>> the below diff in the next revision of this series. >>>> >>>> The 'aux->jit_required' is introduced by following Alexei's suggestion= . >>> >>> I am not sure if introducing a new aux->jit_required member is necessar= y, >>> as we already have a local jit_needed flag in the current logic. >>=20 >> A 'must_jit'-like member was suggested by Alexei [1]. >>=20 >> Probably, the commits in [2] could help to understand 'aux->jit_required= '. >>=20 >> [1] https://lore.kernel.org/bpf/DJMRIZ5PDWP4.12OOZ8H881H6O@gmail.com/ >> [2] https://github.com/Asphaltt/bpf/commits/bpf/fix-interpreter-fallback= /v2/ >>=20 >>> >>> Additionally, the issue reported in my patch [1] is fundamentally tied >>> to bpf_jit_inlines_helper_call(). Maybe we can simply reuse jit_needed >>> by checking bpf_prog_has_inline_helpers() right before JITing, and then >>> reject fallback with -ENOTSUPP if JIT compilation fails. >>=20 >> Correct. Reusing jit_needed is preferred. > > I agree. > > To avoid bloating struct bpf_prog_aux and to keep the refactoring > minimal, I suggest that you submit a patch to introduce a centralized > bpf_prog_requires_jit() helper in kernel/bpf/core.c. > > This will cleanly bundle bpf_prog_has_kfunc_call() and other JIT-only > instructions (like user cast, arena, etc.) together, like this: > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > index 649cce41e13f..4e96272f7377 100644 > --- a/kernel/bpf/core.c > +++ b/kernel/bpf/core.c > @@ -2608,6 +2608,24 @@ static struct bpf_prog=20 > *bpf_prog_jit_compile(struct bpf_verifier_env *env, struc > return prog; > } > > +static bool bpf_prog_requires_jit(const struct bpf_prog *fp) > +{ > + struct bpf_insn *insn =3D fp->insnsi; > + int i; > + > + if (bpf_prog_has_kfunc_call(fp)) > + return true; > + > + for (i =3D 0; i < fp->len; i++, insn++) { > + if (insn_is_cast_user(insn) || > + insn_is_arena_load_store(insn) || > + insn_is_indirect_jump(insn)) > + return true; > + } > + > + return false; > +} No. I already explained that this forking of the logic is not ok. > + > struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env=20 > *env, struct bpf_prog *fp, > int *err) > { > @@ -2620,7 +2638,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct= =20 > bpf_verifier_env *env, struct > goto finalize; > > if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) || > - bpf_prog_has_kfunc_call(fp)) > + bpf_prog_requires_jit(fp)) This has to be fp->jit_required and the verifier has to set it when necessary.