From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (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 D370744CF5B for ; Tue, 20 Jan 2026 18:19:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768933155; cv=none; b=qoanGUwRSSPcvWlbC72MWNwBDugUHtSbRQIACrk7Y+78V5VdS7pVSgN6yXCeMGYsxxPVC144X8dFi3XcxJNcxEnrh/RvFvH/hPqR55fiGAo7bctiUJVMy1uMId4I+UG/Z67LFUP3lrJoB3nIFae3KhlcnhnKxFWo1elc8539lIU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768933155; c=relaxed/simple; bh=Z6WkaZNjD+eEC5S2sCu+mWSNmR7uwq/DhhVRU9ARdG0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=fE6gLQP4p3vDBwCXhnNTeUoNlCBdJO1F/ajvuv0bkMmUzBLuy7gjHwRYvSAYx7SRTUAen6KL/XSRR7TzLvQp0A92FANl3/hcupV/QjR45oCMQ/0yEUR6ztKajGYjUPmc0fellFl4WuSiheSXmoB+1S9PbWjJo7wrJR9fs5EbA5U= 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=nSKLxziI; arc=none smtp.client-ip=74.125.82.53 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="nSKLxziI" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-12448c4d404so4620914c88.1 for ; Tue, 20 Jan 2026 10:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768933153; x=1769537953; 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=SBww9KLEHQwBhj2b72CiEvbmeQf+WrCHcUWGacrEJTM=; b=nSKLxziIag/pKIfQCKmFiGkaJ10nI3Vn1oWj9LoMCM4B/JQIUJjJtXIp80lS0/n4rs u/6JuYY3/WpvkahE7NmVWNvO9e1jete2f9sK81KcilSOvIYsS7U+6RATjtIzd5g0Zq2+ GRHKFYGBI/mpgqpLo3eepLVmbbZO/muS28mGiU8EabYjxlSk+Uo3WmodNscZk5HF8bek X/igo3BykZ6TozWfgSUvFimICZhxgKdKliCMF62DOim4yMFAZGv+vkuSusU2YAL/Tq2T ZsGmEZC5bppH+HWhqImSfp9lXven/RxZk0J3DvdyTqwLuGlFB5iicdiEDXUaA9BOIE2B tXQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768933153; x=1769537953; 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=SBww9KLEHQwBhj2b72CiEvbmeQf+WrCHcUWGacrEJTM=; b=q1LPhaQbcG+NShIC2kBpF1u3pi4PWRCRuQ15ytxiGo7/mbb7uqszRP1jrDPXfe7eH4 kmlKCY+MCOIIyELYUhZNzIKQI2IMaElRyHAbkZdVOUOr2HWBpUGROIqBw6H5c6YPJwYZ nFBPwwwvJJQjpU7Ma20NCVKxv+S1TkKP+BvUBATXib2wjBsArutkwD1v/EEeHHT5uFQv VnnL2/DsQ4LskFcHYRl586Ikf92oFFUaW6vdzcuJCb/iVZtouLnAICeJKAWX47ZUlndl mksmcWb3nExzCJ5Y+fRcBBmUQ5MQLCWhvOaRy/iTZDTgQ54LOFPVl3saHAC5mCOMP9LR OxDQ== X-Forwarded-Encrypted: i=1; AJvYcCXqXy2RxexkH0uhJwnQAn0nnBzPVaVlghIg0C+CLOH40BO3hDAeY2KgJLzXcApquvDtxjCp6o99rkcn9g8=@vger.kernel.org X-Gm-Message-State: AOJu0YwL/m2N3p4yOoR81V6MCyHQfNQWzoDGEdBt3yFhd9w5Si3TKXkD 3bUUr3XLG8Uij9V94Fa+cnsARss7DMekS259H7b7Vnny6YlaOG2nBKdO X-Gm-Gg: AY/fxX6I7W4yWPxiQegy4fzcUkpglXQ2VF+XhaXhObxiEe60axg4ZbrJ9+3ZtnVdcuy 4zaqdoKRLnuhMl3gsiACBhHG1S3XeNgrKsJDVpeC8h5PpiGEOFTnYfa7yvBmaUGRfDuA+E7oONs gSs6wPR9h6MQTWL0FU0cwnOgBe2sRgyDlkJWRSpNGpsc/VUNAAmJsUQDUfIOiQcbBQE7cPV8yHS kT7g6C02F6UEsC0An8aKP1s85r3ceyO9JTNMAW67Mnz7dO5iPT1h5zjiRsUIsQ05equ2nsdDZo0 Dk2bhvA62ZDo2Og2JTJb3DYqkKi+y8Cyn763v2PT4J4XA0ZnhzWAuIzLgDd7Hwzlm27cfePo7Mr /oK94mtpfZMFj4+NiIKjkDXah0L0aMZZIFWgslXKfD+qHqcfRPkV1ZC8TxmjO9TYzXubpKzCbkf NRla7CDuWd4+L7OeTqdruDRbszy9YTsyPLYJxr3PFXMZdV2Uq3O0uKIbnV0+w2v2dnk1uq X-Received: by 2002:a05:7022:e1a:b0:119:e55a:9be7 with SMTP id a92af1059eb24-1246a955faamr2004520c88.3.1768933152685; Tue, 20 Jan 2026 10:19:12 -0800 (PST) Received: from ?IPv6:2a03:83e0:115c:1:b08c:bb3d:92b9:704d? ([2620:10d:c090:500::3:93b1]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1244aefa7c5sm22503340c88.10.2026.01.20.10.19.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 10:19:12 -0800 (PST) Message-ID: Subject: Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize_btf() step 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: Tue, 20 Jan 2026 10:19:10 -0800 In-Reply-To: References: <20260116201700.864797-1-ihor.solodrai@linux.dev> <20260116201700.864797-5-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 Tue, 2026-01-20 at 10:11 -0800, Ihor Solodrai wrote: [...] > > > @@ -1099,12 +1116,22 @@ int main(int argc, const char **argv) > > > if (obj.efile.idlist_shndx =3D=3D -1 || > > > obj.efile.symbols_shndx =3D=3D -1) { > > > pr_debug("Cannot find .BTF_ids or symbols sections, skip symbols r= esolution\n"); > > > - goto dump_btf; > > > + resolve_btfids =3D false; > > > } > > > =20 > > > - if (symbols_collect(&obj)) > > > + if (resolve_btfids) > > > + if (symbols_collect(&obj)) > > > + goto out; > >=20 > > Nit: check obj.efile.idlist_shndx and obj.efile.symbols_shndx inside sy= mbols_collect()? > > To avoid resolve_btfids flag and the `goto dump_btf;` below. >=20 > Hi Eduard, thank you for review. >=20 > The issue is that in case of .BTF_ids section absent we have to skip > some of the steps, specifically: > - symbols_collect() > - sequence between symbols_resolve() and dump_raw_btf_ids() > It's not an exit condition, we still have to do load/dump of the BTF. >=20 > I tried in symbols_collect(): >=20 > if (obj.efile.idlist_shndx =3D=3D -1 || obj.efile.symbols_shndx =3D=3D -= 1) > return 0; >=20 > But then, we either have to do the same check in symbols_resolve() and > co, or maybe store a flag in the struct object. So I decided it's > better to have an explicit flag in the main control flow, instead of > hiding it. For symbols_resolve() is any special logic necessary? I think that `id =3D btf_id__find(root, str);` will just return NULL for every type, thus the whole function would be a noop passing through BTF types once. symbols_patch() will be a noop, as it will attempt traversing empty roots. dump_raw_btf_ids() already returns if there are no .BTF_ids. [...]