Received-SPF: pass (google.com: domain of linux-kernel+bounces-17426-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i6a694271:Fastmail
Date: Thu, 4 Jan 2024 19:37:58 -0700
From: Daniel Xu <dxu@dxuuu.xyz>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: benjamin.tissoires@redhat.com, hawk@kernel.org, edumazet@google.com,
 	alexandre.torgue@foss.st.com, ebiggers@kernel.org, tj@kernel.org,
 rostedt@goodmis.org, 	shuah@kernel.org, martin.lau@linux.dev,
 ast@kernel.org, fw@strlen.de, 	kuba@kernel.org, pablo@netfilter.org,
 jikos@kernel.org, john.fastabend@gmail.com, 	mcoquelin.stm32@gmail.com,
 mhiramat@kernel.org, yonghong.song@linux.dev,
 	Herbert Xu <herbert@gondor.apana.org.au>, dsahern@kernel.org,
 hannes@cmpxchg.org, lizefan.x@bytedance.com, 	pabeni@redhat.com,
 steffen.klassert@secunet.com, daniel@iogearbox.net, 	tytso@mit.edu,
 andrii@kernel.org, davem@davemloft.net, kadlec@netfilter.org,
 	song@kernel.org, alexei.starovoitov@gmail.com, quentin@isovalent.com,
 	alan.maguire@oracle.com, memxor@gmail.com, kpsingh@kernel.org,
 sdf@google.com, 	haoluo@google.com, mathieu.desnoyers@efficios.com,
 mykolal@fb.com, 	linux-input@vger.kernel.org,
 linux-kernel@vger.kernel.org, fsverity@lists.linux.dev,
 	bpf@vger.kernel.org, cgroups@vger.kernel.org,
 linux-trace-kernel@vger.kernel.org, 	netdev@vger.kernel.org,
 netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
 	linux-kselftest@vger.kernel.org,
 linux-stm32@st-md-mailman.stormreply.com,
 	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH bpf-next 2/2] bpf: treewide: Annotate BPF kfuncs in BTF
Message-ID: <kblwkuzcblwogxqjv6vgkwat3wuwpopdmk25smlbz3nho7qhes@2dfdponsqxwo>
References: <cover.1704324602.git.dxu@dxuuu.xyz>
 <68d5598e5708dfe3370406cd5c946565ca4b50f1.1704324602.git.dxu@dxuuu.xyz>
 <ZZaZf_8RuX2xqZGf@krava>
 <bix2uwya2mnk2vgno3vkdpg5kyusq763bmfj2ov6zwpbva6q4h@nqgm3vk4byh5>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bix2uwya2mnk2vgno3vkdpg5kyusq763bmfj2ov6zwpbva6q4h@nqgm3vk4byh5>

On Thu, Jan 04, 2024 at 06:17:50PM -0700, Daniel Xu wrote:
[...]
> > 
> > also given that we can have modules calling register_btf_kfunc_id_set,
> > should we just return error instead of the warn?
> 
> It looks like quite a few registrations go through late_initcall(),
> in which error codes are thrown away. I'm looking at
> init/main.c:do_initcall_level:
> 
>         for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
>                 do_one_initcall(initcall_from_entry(fn));
> 
> Higher level question: if out of tree module does not follow convention,
> it would still make sense to WARN(), right?

Ah, I got what you meant now. I'd say returning error makes sense but
WARN() is also useful. I'll send v2 with both.

[...]