From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f169.google.com (mail-dy1-f169.google.com [74.125.82.169]) (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 66E4E19D071 for ; Tue, 20 Jan 2026 01:49:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768873766; cv=none; b=pDpfq3vQPCMkjwkfhK0iegsXKopX1HafPRU+fERnFgDSZZkoqj2myxC/ELsaBRIURiCLz/Vwvbx9bgGidBWukYyddCLSeDQs1E34F/zI25oir6GIvMpIE5E7obd+Id7kP1gQ5GmLtBhida6U7TgbjXAx/brsm5iMHP3XPfrF6Qg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768873766; c=relaxed/simple; bh=DFMDqIBxWMeUoPAyaqN8hr45MYvMg+GV75NoJCt74uw=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=kXvK3m4RYl8Pdd7k7K9WQvWyXtJng6bQ0CGlTCnBLphYZUplr1uUMGA5Le0Z6WeA8mLdRj7eFL+Epc4ExUbydI/25IGGw0HmpufKco0oSvhvEhz76BIesUf82xIYebh7tbquZUfsy3wuvTcgNhlP5wgGosNxpo4sD37hsuHGs/c= 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=YGQOhK8j; arc=none smtp.client-ip=74.125.82.169 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="YGQOhK8j" Received: by mail-dy1-f169.google.com with SMTP id 5a478bee46e88-2ae255ac8bdso8850642eec.0 for ; Mon, 19 Jan 2026 17:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768873760; x=1769478560; 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=Bs/xgeR13/qdRJT1LBeIlLMVbrV4KZcmi7z58cgPbxU=; b=YGQOhK8j0f4SURUavnyQ7iX+XYkA1JhknqNoJ2EasR7qymsQgNerJPBBHsZkFHRxov HuepDaeLtj75f+JZXT1iW2Wp4qwFRxop99yfVuq0pPKn5rPuuxWf0TIAgxo3qSRz2968 5ASBFN35PX2r7hmYQD1gePiJ3JEA1S1R1mAxFaZIj7NRN1K1blFmsHu6qQFzjE5mNC/l vNfH79YVVMz0fgMKzt8DFlMYtlK/V3PG3C+vUNCyoWdhN135a8BC0St8DNrQ6WZh8Fyh zxVUHGt57OrJ+IlON3Qb3W9tlm+okKrc6nazfkSiFr2uf3bMZYZaId/9fVo6beOMMFOD A3MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768873760; x=1769478560; 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=Bs/xgeR13/qdRJT1LBeIlLMVbrV4KZcmi7z58cgPbxU=; b=B9P7gQxjL64nCzmpmuHvHsYUYQXCbjbtpCi520Aixr5P7jqS0Mp9K8U1AY6n0hhUN7 bNxv9oyFAtFLw1DVV3S4QzDyqBJOcPBceVeE1/GixjxRDplxAH02xFNSGZkr4tSOHLMK b49Pkwqos+gMGmXYaNGN5g2aYMWgTLsFm8Lfo3BievNqSBWi+xZwi3C4EMmp/FRh4Y4V wKwmNHQLDroegKpl3J282bSE+M9u+3NDeY4E4IouxyWpOQgZSkz5uxKvliQ5qM2tTa0e xqlRbmOhvcU2au+Rr+5t/Ibq9C6k5asz+SsJ080yYTpvn71Tvzil17IB2CwsfPgpzwVC zpjw== X-Forwarded-Encrypted: i=1; AJvYcCXCwPJPIs/7TPpCl8PucmAMX4zSSbgor5RayZfy3RbbD9jpZ/FmQXghWLh5keubmN8ZsEM4najw5gRCsjU=@vger.kernel.org X-Gm-Message-State: AOJu0YyOSRpnmPgq/FFA8RAqYBRquFuOFyuWrHiGJZhqeLcyvMnRpiMf jvEbAAUpEw2+EGAEiS2BSMDer+PVr4e5cGBPdkrn0hF5c6/yKxlpWsZtfD/t2R2X X-Gm-Gg: AZuq6aIh6vwtMMQY6jxBUdQTVrKjMujXUvz8vwdYVxwNDvGCpwxXrljOSfY2JHJOnDL AcMSvJFg6GW5XCL5pqDqbRuh8AOOWBGXMaFRTuq/NNopS/Rv0bgtIA6f0vQ1yr1GFskmAefOMDU rPyhYSxcAv6gRJiKTN1WaTa/s4QLHUE3+Rfh2+OmfxM1CTZakpAYHt3lQ/Rh60KzYLmsr7MYzhA pdQolXhoySa/Kk8S63R1ibOnlBFKMWA2n4TYxZQtVvhHTfS6EZ4dMJi1jIkVj4+lAeY2EQl35kB BtOBqnUJDg2hJcbGfEAAeneA4Gd7Htyxrin35Ab6Q69mtvvIu4esp69ZGfVMnTzPWgjkS1+cS9B XOLlvrmd0KYy7YMH5PjI6OA7/94J0gU7dwZI/c0HD72UJtMeaptuuRMoqYncdtGc1uYrcjKYeb2 Zm8Xp/yauVH9KmSamOhLX8cLXVSc3Uv5HPFrh+pU7gZ7fOt0whDdmgnuyuUv0gU3KQ1GYTqtSJo CDO X-Received: by 2002:a05:7300:dc85:b0:2ac:2480:f0ac with SMTP id 5a478bee46e88-2b6b40d991cmr8107963eec.23.1768867408672; Mon, 19 Jan 2026 16:03:28 -0800 (PST) Received: from ?IPv6:2a03:83e0:115c:1:4cd6:17bf:3333:255f? ([2620:10d:c090:500::aa81]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b6b3679980sm15230498eec.31.2026.01.19.16.03.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 16:03:28 -0800 (PST) Message-ID: Subject: Re: [PATCH bpf-next v2 03/13] bpf: Verifier support for KF_IMPLICIT_ARGS From: Eduard Zingerman To: Ihor Solodrai , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau Cc: Mykyta Yatsenko , Tejun Heo , Alan Maguire , Benjamin Tissoires , Jiri Kosina , Amery Hung , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, sched-ext@lists.linux.dev Date: Mon, 19 Jan 2026 16:03:25 -0800 In-Reply-To: <20260116201700.864797-4-ihor.solodrai@linux.dev> References: <20260116201700.864797-1-ihor.solodrai@linux.dev> <20260116201700.864797-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-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-01-16 at 12:16 -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 > 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. >=20 > In order for 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 > __prog suffix is still supported at this point, but will be removed in > a subsequent patch, after current users are moved to KF_IMPLICIT_ARGS. >=20 > Introduction of KF_IMPLICIT_ARGS revealed an issue with zero-extension > tracking, because an explicit rX =3D 0 in place of the verifier-supplied > argument is now absent if the arg is implicit (the BPF prog doesn't > pass a dummy NULL anymore). To mitigate this, reset the subreg_def of > all caller saved registers in check_kfunc_call() [1]. >=20 > [1] https://lore.kernel.org/bpf/b4a760ef828d40dac7ea6074d39452bb0dc82caa.= camel@gmail.com/ >=20 > Signed-off-by: Ihor Solodrai > --- Acked-by: Eduard Zingerman [...] > @@ -14177,8 +14223,12 @@ static int check_kfunc_call(struct bpf_verifier_= env *env, struct bpf_insn *insn, > } > } > =20 > - for (i =3D 0; i < CALLER_SAVED_REGS; i++) > - mark_reg_not_init(env, regs, caller_saved[i]); > + for (i =3D 0; i < CALLER_SAVED_REGS; i++) { > + u32 regno =3D caller_saved[i]; > + > + mark_reg_not_init(env, regs, regno); > + regs[regno].subreg_def =3D DEF_NOT_SUBREG; > + } But we still need to understand why .subreg_def assignment can't be moved inside mark_reg_not_init(). [...]