linux-kernel - Re: [PATCH bpf-next v2 01/18] bpf: add function hash table for tracing-multi

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQ+zkS9RMpB70HEtNK1pXuwRZcjgeQjryAY6zfxSQLVV3A@mail.gmail.com>
Date: Mon, 14 Jul 2025 18:55:03 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>, 
	Menglong Dong <dongml2@...natelecom.cn>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 01/18] bpf: add function hash table for tracing-multi

On Thu, Jul 3, 2025 at 5:17 AM Menglong Dong <menglong8.dong@...il.com> wrote:
>
> We don't use rhashtable here, as the compiler is not clever enough and it
> refused to inline the hash lookup for me, which bring in addition overhead
> in the following BPF global trampoline.

That's not good enough justification.
rhashtable is used in many performance critical components.
You need to figure out what was causing compiler not to inline lookup
in your case.
Did you make sure that params are constant as I suggested earlier?
If 'static inline' wasn't enough, have you tried always_inline ?

> The release of the metadata is controlled by the percpu ref and RCU
> together, and have similar logic to the release of bpf trampoline image in
> bpf_tramp_image_put().

tbh the locking complexity in this patch is through the roof.
rcu, rcu_tasks, rcu_task_trace, percpu_ref, ...
all that look questionable.
kfunc_mds looks to be rcu protected, but md-s are percpu_ref.
Why? There were choices made that I don't understand the reasons for.
I don't think we should start in depth review of rhashtable-wanne-be
when rhashtable should just work.