From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (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 9194D34F270 for ; Wed, 1 Jul 2026 18:47:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782931654; cv=none; b=kAGg+M43g7mX4rSLQgo15w+o4+jqV7+olIa1ieH8mMSDGSqL7ry5fliPiv38miU39htM1obOGNRuWHVEGKulhqHURXkbV/6lUE8cDM9+RsL/hU5ALb1FaU3c4MjFTIafRtyedIC+KECuPlw9uI/dJRyOvbSFK9cjd4jcQ6WvYlg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782931654; c=relaxed/simple; bh=UMZ/oHufdmLrRebJhJdd4z9UveNzoktn4s6GK0qVg9Q=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=W+2rRFAWraLl/IbU4tEpkA6UeECOf5qjFEfYPtcqkl/28ID5yKPxbFUGZAd41q7L+YfW2xs1VsO7Fo4ySaOBA05YhJ6giiBW41/EdzZjOmckaD5z7zubKCCvyYvyl+dXY++2puNVpJ9rjhHB/NckGAVSEWiv1cgV4MLUvCZXg8s= 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.46 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-f46.google.com with SMTP id 46e09a7af769-7e9483cd614so816251a34.1 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=JdWgFzqW7nDURZbzIb+6bFL2VmaY92L0igvScGbnjTSaTok7GtGuaBHKr/LgXyo7Z2 QAzqL68XHtXMnTQHm+fXbjei/bkTla1yXUU+7FptCYJbGZJXjQO6xfaZDy16UfXxP0S4 8QG2+Nn+vVaAAADW9bSg821Z6Dy7Pzan6NzuaBFNhP4OY/ZKZcOUC6WL8gtjDt6SCo9N 02aCAVbO9WWKok0Y6tv9DF845sdWNifzqNSz3KSBcLfFw3dbB0PT0JQaoiU/MRpuxnrZ TvbejqKwO60gQ2/t378dWzcM298B2LBmRaAW48es2FWDZLOI8wHlDm4ZiecGN5EWnPGW FIBg== X-Forwarded-Encrypted: i=1; AFNElJ8nMNx70yKp9M1PIZ7eLVyvF8QFmVSYqkJl1fTJQrwzJ3eaX00MjtC27bb/YsUiPvRSf+sG3KfAngTO9bw=@vger.kernel.org X-Gm-Message-State: AOJu0YzlaWD/rLRWBk/d7vA3uKePN2hWdZNe/ifDywM6RpxnaiAp7Ndt WbduGfbndBKkHKp2rWRE7UY979mZpwwY4ao410IJ4YYhNicz57Qf8jgV X-Gm-Gg: AfdE7ckkbaDdXdmQS+5LmSeM2LcLyLh5DIq6df7vnoDCupeEYFpQ4X0R8buMBg1+ZrR p5eIQjthznGGX7iTLD+YOOjj3MjsQCEgx3CRypN+iBJ2uuPEWLaDYl+yfJDH+ydBZ3/Jt+1w6W2 MNf/oh6xZbK8du+/hawlZqW4LelLG3Ekzkx6gB1C0rsbMUwvBYyisoBYUPXLFhXUpb1BqslSBci 3Pnf6qiNC6IQS/q0b3A3bqhAel4ILMQOIyhxsceIwc8OR/bwLcJJ8Aq3bicP+LXwvvxAMBEKN7R 9YrHfApgNsrD9r/Y9XAYpHlSq+0ZcGYYjDsDDgtkoEcMQeyi7/mAQlIDhK0A0qznwYXTHeeswsv MyoW2w1ibx2mv+ZlS3nbz7YbhQlOssz/UVhZkcBH7IaLY4EXQl2gQPyxYjsvuMKHrFEDCw5Jlh8 bNhVwuCKy3ScwS5IImZtZJDWC9vqH1Ku7WbkBxqL1txbwHA81/HLE8/Omr5C5hLrVtFRdIPYpd3 16c3Q== 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-kernel@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.