From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 7FCCE276051 for ; Tue, 13 Jan 2026 20:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768336780; cv=none; b=lQITNWy8Ve+vNbQtZ2gYy3H78vJcwb8BsBVpYaPeNLBgbbm40w3F1YYauTjxgHqfyHPpnnxHpblSmu5S4i6M09ctqNGzCsse4UAE9yoYJ5TMs5KK47y86jXASh3z9/gwKSp51hiMKSu6C7mXT3zqj4NwjUQu7w3JvYzQc6yh2dw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768336780; c=relaxed/simple; bh=5G/+O4AfoFl7Mun62PXu7YMTfSDOOK90wf7hCG0XoWM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Na9ekpbLFK1TY5wMjOQJv1qQGeJq1XUCVN4ofLmTnFE0uB4azgibkegPMA5MN+gkbyO2aVUPHJJ3YLy8NsOftLJ/335AQ95Vfni7KOBQAGSfPpSJ1T6F9vNXBBThmBCxIRgXjOz6oIerPPnV3AvMhtxDVZ8UfcNETjNPErmN3lc= 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=VuiKHgIr; arc=none smtp.client-ip=209.85.214.173 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="VuiKHgIr" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2a0d6f647e2so79488875ad.1 for ; Tue, 13 Jan 2026 12:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768336779; x=1768941579; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=vuKJVwdXdLFoBFmdbdguCpeTwBYgUktjFchgdX5Irfo=; b=VuiKHgIrGqdniq6cfe8yQe1Ae2YdksGWyylrbInAtjq3QwVSaARsjPohyPcG97stx9 iSEZY3mG3EYygxV7m9g3+Bnse0KOW8UeBiJApkXXPuEqe8HkOuyzvJ+qOQ6M/C+cJtcR kwfAQsKSEUX5N8rNvHNNslbDBgs3X8V9lNFKMiYIe/yiJL75eOH+M6kwe0WimgSjVRNY IZ5DLoEi8E+/efVAeJ/KRQEX9USeRQJ7hNW6rlLsHlPR8xFx6BqA2v+9rTnuzgEeNcTx pNnX5kO5VUMNWPh+dWFWsOX30cTbX6GVKs1AD/zf/Ooa93CH2WFIk91PHxQoB0jtIsaR 6djA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768336779; x=1768941579; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vuKJVwdXdLFoBFmdbdguCpeTwBYgUktjFchgdX5Irfo=; b=IjoE3kfuOlOSXRhP3iUzVlpL29JLW0bgBvGZHjSHHC7yE21okknwrqS2NjQvwy7Za4 Tv2XCwMIrQsJEiKhtwnSFkoYEaPzQgKNr5txKnGkLtlrN1nx2Kn+yapqYjQRp1XmaTUN oHij9QFFxffvBA9K56JkvEQOWP6MdFczSM5Qb5OQfGcuYfvO77N5i6JhZGESSK6y6JUc CW2F+bIKBqSp41Hb+Kxi2GshZ4JE4OsovsrQ42ER+kXFtuxaeCnJ5+hDA/2etUVi4He4 yfCJWe41pj0xE87SKAgAhDUZe3HLcfzpcz1cHS7AH/CPMjd3Mdg36k88Mp/37cH9K4F/ DKnw== X-Forwarded-Encrypted: i=1; AJvYcCWruSnh4BP5xVYtX0eXM4etxesE05gpr9UTIwGAgOYicH4jHZhSxU3OTC1vnvbzZBXT6pEa6iM+w8WfQg==@vger.kernel.org X-Gm-Message-State: AOJu0Yyw7F5Q4ygLavFFObd4BKtPh/+5j+zEkT2JGu6CmIexanKXC+Un TmBc+44Kk92YAc9zadxfgxeh+L2EBco2j7SRu0DquMYIikynp8MmwB7g X-Gm-Gg: AY/fxX5XIadGq8nphw61+e/Cp1hnh3RstSEYMbAhLwW4xSEnEVgh06kppE6+VEdTwMI uo6aKArIFcCw2IU/FQBCzRibTVGMmemZw2g4gdK3rIdL4k41AHDY3cSFBntdTGVEsTnAcjhklgL 35Tac4Ahq5jGi9RGIwYoaJ1La/Nlgw9XiTQ5ji/9Rtcs4oIK5oNgBe5OqHKfjxYyFpKu/sW5Isp 9Fk3kcK4tYXPUwHXLWyLkGHQ/pfhivymb8zE1YTm2eqIUQkPx8Uo69nyij1aXkaSISB9aBUzE7O dPtpFbmYKK6uda/5vho/6QYy6XwGhZ/es1Mo76JX3pA+Z7tweyJ0kBXNeA1b+v2HsbNFs0jVGOX 8O54fRCdsLHCJDMDS/5FWBHKUelG9Si0bAK+PtHkmeDUCddOLTtoKcEdSpvX6Z9cjsNwlEWQBsj 7at+D0dhtthBC6h7aJQL2eK2FTjknjqXCA1BfvpA2a X-Received: by 2002:a17:902:f651:b0:2a3:bf5f:926c with SMTP id d9443c01a7336-2a599e3434fmr3125395ad.39.1768336778822; Tue, 13 Jan 2026 12:39:38 -0800 (PST) Received: from [192.168.0.226] ([38.34.87.7]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c4cbf28f6cdsm20541766a12.6.2026.01.13.12.39.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 12:39:38 -0800 (PST) Message-ID: <952853dd064d5303a7e7ec8e58028e9ee88f2fad.camel@gmail.com> Subject: Re: [PATCH bpf-next v1 03/10] bpf: Verifier support for KF_IMPLICIT_ARGS From: Eduard Zingerman To: Ihor Solodrai , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau Cc: Mykyta Yatsenko , Tejun Heo , Alan Maguire , Benjamin Tissoires , Jiri Kosina , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, sched-ext@lists.linux.dev Date: Tue, 13 Jan 2026 12:39:35 -0800 In-Reply-To: <20260109184852.1089786-4-ihor.solodrai@linux.dev> References: <20260109184852.1089786-1-ihor.solodrai@linux.dev> <20260109184852.1089786-4-ihor.solodrai@linux.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-input@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-01-09 at 10:48 -0800, Ihor Solodrai wrote: > A kernel function bpf_foo marked with KF_IMPLICIT_ARGS flag is > expected to have two associated types in BTF: > * `bpf_foo` with a function prototype that omits implicit arguments > * `bpf_foo_impl` with a function prototype that matches the kernel > declaration of `bpf_foo`, but doesn't have a ksym associated with > its name >=20 > In order to support kfuncs with implicit arguments, the verifier has > to know how to resolve a call of `bpf_foo` to the correct BTF function > prototype and address. >=20 > To implement this, in add_kfunc_call() kfunc flags are checked for > KF_IMPLICIT_ARGS. For such kfuncs a BTF func prototype is adjusted to > the one found for `bpf_foo_impl` (func_name + "_impl" suffix, by > convention) function in BTF. >=20 > This effectively changes the signature of the `bpf_foo` kfunc in the > context of verification: from one without implicit args to the one > with full argument list. >=20 > Whether a kfunc argument is implicit or not is determined by > is_kfunc_arg_implicit(). The values of implicit arguments by design > are provided by the verifier, and so they can only be of particular > types. In this patch the only allowed implicit arg type is a pointer > to struct bpf_prog_aux. The __prog args (usually void *) are also > considered implicit for backwards compatibility. >=20 > In order to enable the verifier to correctly set an implicit > bpf_prog_aux arg value at runtime, is_kfunc_arg_prog() is extended to > check for the arg type. At a point when prog arg is determined in > check_kfunc_args() the kfunc with implicit args already has a > prototype with full argument list, so the existing value patch > mechanism just works. >=20 > If a new kfunc with KF_IMPLICIT_ARG is declared for an existing kfunc > that uses a __prog argument (a legacy case), the prototype > substitution works in exactly the same way, assuming the kfunc follows > the _impl naming convention. The difference is only in how _impl > prototype is added to the BTF, which is not the verifier's > concern. See a subsequent resolve_btfids patch for details. >=20 > In check_kfunc_call() reset the subreg_def of registers holding > implicit arguments to correctly track zero extensions. >=20 > Signed-off-by: Ihor Solodrai > --- Overall lgtm. [...] > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c [...] > @@ -14303,6 +14358,17 @@ static int check_kfunc_call(struct bpf_verifier_= env *env, struct bpf_insn *insn, > for (i =3D 0; i < nargs; i++) { > u32 regno =3D i + 1; > =20 > + /* > + * Implicit kfunc arguments are set after main verification pass. > + * For correct tracking of zero-extensions we have to reset subreg_def= for such > + * args. Otherwise mark_btf_func_reg_size() will be inspecting subreg_= def of regs > + * from an earlier (irrelevant) point in the program, which may lead t= o an error > + * in opt_subreg_zext_lo32_rnd_hi32(). > + */ > + if (unlikely(KF_IMPLICIT_ARGS & meta.kfunc_flags > + && is_kfunc_arg_implicit(desc_btf, &args[i]))) > + regs[regno].subreg_def =3D DEF_NOT_SUBREG; > + Did you try doing this in `mark_reg_not_init()`? This function is called for R1-R5 some time prior this hunk. What I don't like from structural point of view is: - `is_kfunc_arg_implicit()` depends on KF_IMPLICIT_ARGS, but that check is done externally. Hence, the naming is misleading or 'meta' should be passed to `is_kfunc_arg_implicit()`. - doing DEF_NOT_SUBREG logically has not much to do with implicit args, so it is a bit confusing that is pre-conditioned like that. > t =3D btf_type_skip_modifiers(desc_btf, args[i].type, NULL); > if (btf_type_is_ptr(t)) > mark_btf_func_reg_size(env, regno, sizeof(void *));