linux-kernel - Re: [PATCH bpf-next v3] bpf: Remove redundant checks

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: <20250417133641.7518-1-yangfeng59949@163.com>
Date: Thu, 17 Apr 2025 21:36:41 +0800
From: Feng Yang <yangfeng59949@....com>
To: andrii.nakryiko@...il.com
Cc: andrii@...nel.org,
	ast@...nel.org,
	bpf@...r.kernel.org,
	daniel@...earbox.net,
	eddyz87@...il.com,
	haoluo@...gle.com,
	john.fastabend@...il.com,
	jolsa@...nel.org,
	kpsingh@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org,
	martin.lau@...ux.dev,
	mathieu.desnoyers@...icios.com,
	mattbobrowski@...gle.com,
	mhiramat@...nel.org,
	rostedt@...dmis.org,
	sdf@...ichev.me,
	song@...nel.org,
	yangfeng59949@....com,
	yonghong.song@...ux.dev
Subject: Re: [PATCH bpf-next v3] bpf: Remove redundant checks

On Thu, 17 Apr 2025 17:52:45 +0800 Feng Yang wrote:
> > >         case BPF_FUNC_get_smp_processor_id:
> > >                 return &bpf_get_smp_processor_id_proto;
> >
> > this one should be cleaned up as well and
> > bpf_get_smp_processor_id_proto removed. All BPF programs either
> > disable CPU preemption or CPU migration, so bpf_base_func_proto's
> > implementation should work just fine (but please do it as a separate
> > patch)
> > 

> BPF_CALL_0(bpf_get_smp_processor_id)
> {
>	return smp_processor_id();
> }
> const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
>	.func		= bpf_get_smp_processor_id,
>	.gpl_only	= false,
>	.ret_type	= RET_INTEGER,
>	.allow_fastcall	= true,
> };
> When attempting to remove bpf_get_smp_processor_id_proto,
> it was observed that bpf_get_smp_processor_id is extensively used.
> Should we also replace all instances of bpf_get_smp_processor_id with bpf_get_raw_cpu_id in these cases?
>
> For example:
> #define ___BPF_FUNC_MAPPER(FN, ctx...)			\
>        ......
>	FN(get_smp_processor_id, 8, ##ctx)		\

> samples/bpf/sockex3_kern.c:
> static struct globals *this_cpu_globals(void)
> {
>        u32 key = bpf_get_smp_processor_id();
>        return bpf_map_lookup_elem(&percpu_map, &key);
> }
> and so on......
> Thanks.

I think I understand the issue now: removing this bpf_get_smp_processor_id has no impact.

For the code:
 case BPF_FUNC_get_smp_processor_id:
    return &bpf_get_raw_smp_processor_id_proto;

This configuration allows bpf_get_smp_processor_id to actually invoke the bpf_get_raw_smp_processor_id_proto function implementation.
Thanks.