From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9455B3033EF for ; Tue, 20 Jan 2026 18:35:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934133; cv=none; b=ECcHhUb29qLlj0Dz4T54WDhVRqBuOcn8RrgnTC4EXxrx6TEMIYsjxAqxTGfJj5UNEIJu67vnr56ByP6f+bFe5ZyLB/Y1aJRD6LkY2euXgnAXvscCl7wl/xgzZ+IIfDpvjd4aSMyCdk7okxmNdwDzePHJohmic6pTZRer6boapPg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934133; c=relaxed/simple; bh=3yGAGGw5eWKeXtAk627Ima8Gs9AAiwJMGypUvWnlvYE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HP6nzVga73PG9nWMn10ATHtm5DJ6zvK83aR1Njp2jmjXTdRQUbL5ULFi9//ZCUwzS3AcSVvpoXYianAYd3QAkJNC9xwcPZbQNeqAi2lAR+a19R+zWbASH2zkLqVIKBiPxN7z6J73HgQgeSdzXzx4g9XvLxur/46lORM3Ps+liF8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=uX7T5YOC; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="uX7T5YOC" Message-ID: <74fbaa99-024b-4e42-bda0-99ae792d565b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1768934119; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JLPdwWhpS0HfKC6t7quQPU7Dg+w9SU30pGQamQFfJ0E=; b=uX7T5YOCVxExz4iuE0ffYSfWjc7vimAiDySGGUFu+5hk0i2U2XKKLkj0k93Jx9Oi+fdKB/ s+bCqaGRFqMNCkV/mlj4vX/zyxiENhXkOMerJEp7mXP92Aa469YgM3JsjzFpzZwD3ReqTt 1HmmukJIA9da3FjgPmndXOoDJqSAE9U= Date: Tue, 20 Jan 2026 10:35:13 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize_btf() step To: Eduard Zingerman , 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 References: <20260116201700.864797-1-ihor.solodrai@linux.dev> <20260116201700.864797-5-ihor.solodrai@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 1/20/26 10:19 AM, Eduard Zingerman wrote: > 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 == -1 || >>>> obj.efile.symbols_shndx == -1) { >>>> pr_debug("Cannot find .BTF_ids or symbols sections, skip symbols resolution\n"); >>>> - goto dump_btf; >>>> + resolve_btfids = false; >>>> } >>>> >>>> - if (symbols_collect(&obj)) >>>> + if (resolve_btfids) >>>> + if (symbols_collect(&obj)) >>>> + goto out; >>> >>> Nit: check obj.efile.idlist_shndx and obj.efile.symbols_shndx inside symbols_collect()? >>> To avoid resolve_btfids flag and the `goto dump_btf;` below. >> >> Hi Eduard, thank you for review. >> >> 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. >> >> I tried in symbols_collect(): >> >> if (obj.efile.idlist_shndx == -1 || obj.efile.symbols_shndx == -1) >> return 0; >> >> 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 = 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. Hm... Looks like you're right, those would be noops. Still, I think it's clearer what steps are skipped with a toplevel flag. Otherwise to figure out that those are noops you need to check every subroutine (as you just did), and a future change may unintentionally break the expectation of noop creating an unnecessary debugging session. And re symbols_resolve(), if we don't like allocating unnecessary memory, why are we ok with traversing the BTF with noops? Seems a bit inconsistent to me. > > [...]