public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Ihor Solodrai <ihor.solodrai@linux.dev>,
	Alexei Starovoitov <ast@kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>
Cc: Mykyta Yatsenko <yatsenko@meta.com>, Tejun Heo <tj@kernel.org>,
	Alan Maguire <alan.maguire@oracle.com>,
	Benjamin Tissoires <bentiss@kernel.org>,
	Jiri Kosina	 <jikos@kernel.org>, Amery Hung <ameryhung@gmail.com>,
	bpf@vger.kernel.org, 	linux-kernel@vger.kernel.org,
	linux-input@vger.kernel.org, 	sched-ext@lists.linux.dev
Subject: Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize_btf() step
Date: Tue, 20 Jan 2026 10:40:03 -0800	[thread overview]
Message-ID: <45b3df2a1b83a90c134b265ecd713731173556f0.camel@gmail.com> (raw)
In-Reply-To: <74fbaa99-024b-4e42-bda0-99ae792d565b@linux.dev>

On Tue, 2026-01-20 at 10:35 -0800, Ihor Solodrai wrote:
> 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.

I'd argue that resolve_btfids is written in a clear read data /
process data manner, so it should behave correctly even if collected
data is empty. Is there a difference between no .BTF_ids and empty
.BTF_ids?

> 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.

He-he, I never heard about consistency :)
Just don't like flags, they make me think more.

  reply	other threads:[~2026-01-20 18:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16 20:16 [PATCH bpf-next v2 00/13] bpf: Kernel functions with KF_IMPLICIT_ARGS Ihor Solodrai
2026-01-16 20:16 ` [PATCH bpf-next v2 01/13] bpf: Refactor btf_kfunc_id_set_contains Ihor Solodrai
2026-01-16 20:16 ` [PATCH bpf-next v2 02/13] bpf: Introduce struct bpf_kfunc_meta Ihor Solodrai
2026-01-16 20:16 ` [PATCH bpf-next v2 03/13] bpf: Verifier support for KF_IMPLICIT_ARGS Ihor Solodrai
2026-01-20  0:03   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize_btf() step Ihor Solodrai
2026-01-20  0:13   ` Eduard Zingerman
2026-01-20 18:11     ` Ihor Solodrai
2026-01-20 18:19       ` Eduard Zingerman
2026-01-20 18:35         ` Ihor Solodrai
2026-01-20 18:40           ` Eduard Zingerman [this message]
2026-01-16 20:16 ` [PATCH bpf-next v2 05/13] resolve_btfids: Support for KF_IMPLICIT_ARGS Ihor Solodrai
2026-01-16 20:39   ` bot+bpf-ci
2026-01-16 20:44     ` Ihor Solodrai
2026-01-17  0:06   ` Andrii Nakryiko
2026-01-17  6:36     ` Ihor Solodrai
2026-01-20  0:24       ` Eduard Zingerman
2026-01-20  0:55   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 06/13] selftests/bpf: Add tests " Ihor Solodrai
2026-01-20  1:24   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 07/13] bpf: Migrate bpf_wq_set_callback_impl() to KF_IMPLICIT_ARGS Ihor Solodrai
2026-01-20  1:50   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 08/13] HID: Use bpf_wq_set_callback kernel function Ihor Solodrai
2026-01-16 20:16 ` [PATCH bpf-next v2 09/13] bpf: Migrate bpf_task_work_schedule_* kfuncs to KF_IMPLICIT_ARGS Ihor Solodrai
2026-01-20  1:52   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 10/13] bpf: Migrate bpf_stream_vprintk() " Ihor Solodrai
2026-01-20  1:53   ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 11/13] selftests/bpf: Migrate struct_ops_assoc test " Ihor Solodrai
2026-01-20  1:59   ` Eduard Zingerman
2026-01-20 18:20     ` Ihor Solodrai
2026-01-20 18:24       ` Eduard Zingerman
2026-01-16 20:16 ` [PATCH bpf-next v2 12/13] bpf: Remove __prog kfunc arg annotation Ihor Solodrai
2026-01-20  2:01   ` Eduard Zingerman
2026-01-16 20:17 ` [PATCH bpf-next v2 13/13] bpf,docs: Document KF_IMPLICIT_ARGS flag Ihor Solodrai
2026-01-20  1:49 ` [PATCH bpf-next v2 00/13] bpf: Kernel functions with KF_IMPLICIT_ARGS Eduard Zingerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45b3df2a1b83a90c134b265ecd713731173556f0.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=ameryhung@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bentiss@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=ihor.solodrai@linux.dev \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=yatsenko@meta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox