netdev - Re: [PATCH bpf-next 2/2] bpf: treewide: Annotate BPF kfuncs in BTF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <kblwkuzcblwogxqjv6vgkwat3wuwpopdmk25smlbz3nho7qhes@2dfdponsqxwo>
Date: Thu, 4 Jan 2024 19:37:58 -0700
From: Daniel Xu <dxu@...uu.xyz>
To: Jiri Olsa <olsajiri@...il.com>
Cc: benjamin.tissoires@...hat.com, hawk@...nel.org, edumazet@...gle.com,
 	alexandre.torgue@...s.st.com, ebiggers@...nel.org, tj@...nel.org,
 rostedt@...dmis.org, 	shuah@...nel.org, martin.lau@...ux.dev,
 ast@...nel.org, fw@...len.de, 	kuba@...nel.org, pablo@...filter.org,
 jikos@...nel.org, john.fastabend@...il.com, 	mcoquelin.stm32@...il.com,
 mhiramat@...nel.org, yonghong.song@...ux.dev,
 	Herbert Xu <herbert@...dor.apana.org.au>, dsahern@...nel.org,
 hannes@...xchg.org, lizefan.x@...edance.com, 	pabeni@...hat.com,
 steffen.klassert@...unet.com, daniel@...earbox.net, 	tytso@....edu,
 andrii@...nel.org, davem@...emloft.net, kadlec@...filter.org,
 	song@...nel.org, alexei.starovoitov@...il.com, quentin@...valent.com,
 	alan.maguire@...cle.com, memxor@...il.com, kpsingh@...nel.org,
 sdf@...gle.com, 	haoluo@...gle.com, mathieu.desnoyers@...icios.com,
 mykolal@...com, 	linux-input@...r.kernel.org,
 linux-kernel@...r.kernel.org, fsverity@...ts.linux.dev,
 	bpf@...r.kernel.org, cgroups@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, 	netdev@...r.kernel.org,
 netfilter-devel@...r.kernel.org, coreteam@...filter.org,
 	linux-kselftest@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH bpf-next 2/2] bpf: treewide: Annotate BPF kfuncs in BTF

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.

[...]