From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f9.google.com (mail-wm2-f9.google.com [74.125.225.137]) (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 6F74442E8D0 for ; Tue, 4 Aug 2026 21:46:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.137 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785880017; cv=none; b=CP/KhzbUlqJ+J8f2g4QgTQGEk2sa8tqsHttC/CqldXnr29QzB2c//fG894KvKVugvkD6FfTd14ou/R+MnkGzvpOk9RV+Ksx3WH4NpmRZE+gLR1l6bHBs6qEWRxycCg5wIjmxrsRjZqu35rASZMS0hyDtJ0MCbdXrILlPJpTBFO4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785880017; c=relaxed/simple; bh=TFzYjcQ7cXWKf52aEKHbaRDrsz4SD9u9cG16spEct9E=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=hPC3txKqeeX2zvoRQnRbQkz0Tn6oxfWB64p7KfrLjh41rsafqRsDu9UDz/dZLBPCTAAoOkSDTWZEH70fLBbPGGg54ppHaMzwd2OdSsjbNwwTQKGnah4qnvP1Etigrh1yASUkKnHI9NvziIizdlLfTBVJPReNw2u6k1bFfzFoE3k= 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=g+b+rE/Q; arc=none smtp.client-ip=74.125.225.137 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="g+b+rE/Q" Received: by mail-wm2-f9.google.com with SMTP id 5b1f17b1804b1-49553da76dcso824885e9.1 for ; Tue, 04 Aug 2026 14:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785880014; x=1786484814; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=/HCxSPKGFa03XR0faEHZWkLShPx83eFqGMtoyP3gJeA=; b=g+b+rE/QeZXzeYubgdIew3TnI8JFpWH6KZVwT5F24JfG/ljtQeR/MuiftEcP5y707q HbkW6/hEbq+kQNaAlyXkX1vAaz2I1+ldoZmioMHYoNW2gsTdfw4K0vjmSE9UW6lV4ItT TQlEt/AE7WNThlOebDZdbYCDTSrYdfFLj++3EiaQhlEEHnkhUHRkyMBeMGzbNdvl64nP L87yO/yuRG0iy4sT8ZY85qGf1/aJ4VTyu4qNH8enF9z5EF6+WjQINYWuOsWPSxANcZP/ utljLz+6HE8PiYiFFxqjpOKMNm49fWpAQGPzKZ1otvD01PH5FDkF+p+/gKUtXn5TTIIf QrMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785880014; x=1786484814; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/HCxSPKGFa03XR0faEHZWkLShPx83eFqGMtoyP3gJeA=; b=c8mAZUWyx+slsshn1qfT3VMcdYa8B4IPF2Q46t9Dgi6uZms4WfUjM2PK8cYb71e94A GeS9x5MOmjJuPKNx6N8S/sTyViOBnFVPx2thrgEEcikWZijA82WjZG7bIo0P9PRfDkbW mf8vheSIDokNB5liM4BGWitnVXNE2WadjqoWwSgGKUbp9Ywu+qELmxFgHbmfLQgrmNgz zg3LcpmIrSMngVAS/PaK4/G0WpgY/Vsm7d7aKw3cCMLs5aF0vLl1TngMudowmb6L0s6l gZi4TD8VG8GQVDYr+pBU81yhdOXDGDeV2adqwPVt+vwco/7jAilLAzCZCuc19Uq/GQi+ m14w== X-Gm-Message-State: AOJu0YzTt+J2BWZaXnzuPDupMtvcppNKDu5mf/Mw6JzwIPmilGnIwk7l k32jbLtdoa8VkRXamzo2ATbNa4+yHTk2a3Uo0iRFb85ZeWiZILX8A35h X-Gm-Gg: AR+sD11PJ5O5nPbZEmWEmaudqTaRd+Oi5eQG9ampaCVM9Czi6jjtVjYASQMVAmc0L2f /XT28rO/wBIfy0r+2abXuUyayJ+W67yiDgrwYBaFWjOaK5ANz/XV42Bx7HQnDzUG8L3phoOIIjz LeVRvlV4yHni45ax8TdQnZCqxCwb4yRNMEuCD463SVGpN2MSwFblUZIjYFJwQJsojU5DoshTOrZ 1Q1+hVNSxku9ZSDVUkfyNjh7bqURHWDPUgZQKcEbxeG/0+kvJVVMIXl2hjSlXdNBtx5nhrF3egw bEzVTDrYziVN052uZiLBjK7xdPwWXoOIXUwO9Tq6qckPei2V4zswtJXVCyB+K+uuj2+CtsumWo4 AwebSVpoRST1ByM5DXiImXGhQa8iwa6QLaLwHGAX8ALMmSplvXdkzxNmiskJ0z5bh0L0eMpYhYg /Yj7aba1wOvKjWlBnQqbTDZeWhsoXI9RPTwmg2hWcbmeNoxf/Kf0JXeDp9ZeoHSLQoRMy3C3wLg efa3XQKWPUDjYRrLao0lzpp38Xko22ZKvp8cdp4WqgJ6g8MHIZrBp/rt6T5Tq9z+XJM/DTkvj8t C4erOaVV4O4iFrcsgFX3y26rIIw= X-Received: by 2002:a05:600c:620e:b0:495:6274:56c2 with SMTP id 5b1f17b1804b1-4994e70a6f5mr19571105e9.2.1785880013603; Tue, 04 Aug 2026 14:46:53 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4994dfe64e0sm34458565e9.6.2026.08.04.14.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 14:46:53 -0700 (PDT) Precedence: bulk X-Mailing-List: bpf@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: Tue, 04 Aug 2026 23:46:52 +0200 Message-Id: Cc: , "Andrii Nakryiko" , "Alexei Starovoitov" , "Tejun Heo" , "Emil Tsalapatis" Subject: Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes From: "Kumar Kartikeya Dwivedi" To: "Eduard Zingerman" , "Ihor Solodrai" , "Alan Maguire" , "Arnaldo Carvalho de Melo" , X-Mailer: aerc 0.21.0 References: <20260803125518.2279340-1-memxor@gmail.com> <4cb8bb30-1f01-4b78-a6b1-4ade3b965039@linux.dev> <8dc173dc3d051d338916c72cae070238718fd196.camel@gmail.com> <6c9500d4-7401-44f0-93a6-88a827026ae0@linux.dev> <4d20aecf677f4aec3e8e70106d4bdbcb01902e69.camel@gmail.com> In-Reply-To: <4d20aecf677f4aec3e8e70106d4bdbcb01902e69.camel@gmail.com> On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote: > On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote: >> On 8/4/26 1:22 PM, Eduard Zingerman wrote: >> > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote: >> > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote: >> > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote: >> > > > > [...] >> > > >> > > > >> > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I do= n't >> > > > think we want to introduce and support yet another mechanism for a= rena >> > > > argument annotations. If we do, we'll be stuck with a mess of >> > > > supporting two/three ways of doing the same thing for the foreseea= ble future. >> > > >> > > I think one major difference is that KF_ARENA_ARG* things were mostl= y for >> > > annotating the vmlinux.h with the right address space label before, = but didn't >> > > carry any semantic meaning for the kfunc's type checks. >> > > >> > > That changes with these suffixes though. The pointer will be transla= ted when >> > > passed into the kfunc. IMO it would be odd to diverge for this parti= cular case, >> > > since we use suffixes for every other case where we constrain the in= put type of >> > > the kfunc argument or give it special meaning. >> > > >> > > We also want to have similar annotation on struct_ops callbacks, whe= re we also >> > > use suffixes, so it seemed better to keep it consistent. >> > >> > I agree that we should follow the principle of least surprise here and >> > use suffixes, as everything else uses suffixes as well. >> >> Ok, I understand the motivation. Let's say we use the suffixes. >> >> Should this enable getting rid of KF_ARENA* flags then? For the >> purposes of generating address_space(1), we can also just check the >> name suffix, no? > > That would be ideal, yes. > >> > >> > And yes, the __arena and KF_ARENA_ARG* annotations have different >> > semantics: >> > - __arena means that user space arena address is passed as is >> > - KF_ARENA_ARG* means that a user space address is converted >> > =C2=A0 to a kernel space address before passing. >> >> Also I am a little confused about whether we *need* to be able to >> express two distinct meanings of "arena pointer" or not? >> >> My understanding is that "arena pointer" is a feature of an arg type >> that has a single meaning: the pointer has one base in BPF world, and >> a different base when executed in the kernel. >> >> The things that are missing is auto-conversion (Tejun's RFC [1]) and mor= e >> comprehensive support of PTR_TO_ARENA in the verifier. >> >> This is still only one "arena" annotation per arg. Do we actually need >> the proliferation of __arena, __arena__nullable and/or __arena_kern, >> __arena_user? Can't we have a single defined semantics of how arena >> pointers are supposed to work? >> >> I can imagine something like follows: >> =C2=A0 * arena pointers can not be null, check for nulls >> =C2=A0=C2=A0=C2=A0 before passing from BPF prog to the kernel > > We are deliberately lax when handling arena and don't do any kind of > value tracking there. So e.g. the following won't work: > > if (foo->ptr) { > ... > kfunc(foo->ptr); > } > > Unless compiler decides to keep foo->ptr in a register. I'm not sure > whether enforcing non-null here from the verifier side is the right > call. > >> =C2=A0 * arena pointers are converted to the kernel space for >> =C2=A0=C2=A0=C2=A0 kfunc/struct_ops callback by the verifier >> >> With the documented and enforced semantics like this one way of >> annotating and one annotation should be enough. >> >> What am I missing? > > At the moment we have two consumers: > - Planned sched_ext related kfuncs that need kernel space pointers. > - Existing kfuncs with KF_ARENA_ARG: > - bpf_arena_alloc_pages > - bpf_arena_free_pages > - bpf_arena_reserve_pages > They, take a user space address. Looking at the code is appears that > all three can be changed to handle kernel space address. > On the other hand, neither of these *needs* the passed pointer to be > converted to a kernel side arena pointer. So that would be just some > useless work. I don't think it's useless work, they translate manually because the actual= page table operations happen using the kernel address anyway. IMO they probably = need access to both, and having one gives other, but kaddr is more important for= them to actually carry out the page table manipulation. > > So there are two valid use cases. > > ...