linux-kernel - Re: [PATCH v2 3/4] perf lock contention: Resolve slab object name using BPF

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: <00aa92be-85db-4163-9576-dfc71eafb415@suse.cz>
Date: Wed, 13 Nov 2024 15:20:43 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
 Kan Liang <kan.liang@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
 LKML <linux-kernel@...r.kernel.org>, linux-perf-users@...r.kernel.org,
 Andrii Nakryiko <andrii@...nel.org>, Song Liu <song@...nel.org>,
 bpf@...r.kernel.org, Stephane Eranian <eranian@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH v2 3/4] perf lock contention: Resolve slab object name
 using BPF

On 11/12/24 15:50, Arnaldo Carvalho de Melo wrote:
> On Tue, Nov 12, 2024 at 12:09:24PM +0100, Vlastimil Babka wrote:
> +               /* look slab_hash for dynamic locks in a slab object */
> +               if (hashmap__find(&slab_hash, flags & LCB_F_SLAB_ID_MASK, &slab_data)) {
> +                       snprintf(name_buf, sizeof(name_buf), "&%s", slab_data->name);
> +                       return name_buf;
> +        	}
> 
> He wants to avoid storing 64 bytes (the slab cache pointer, 's'), instead
> he wants to store a shorter 'id' and encode it in the upper bits of the
> 'struct contention_data' 'flags' field.
> 
> The iterator, at the beggining of the session attributes this id,
> starting from zero, to each of the slab caches, so it needs to map it
> back from the address at contention_end tracepoint.
> 
> At post processing time it converts the id back to the name of the slab
> cache.
> 
> I hope this helps,

Thanks a lot, if it's a tradeoff to do a bit more work in order to store
less data, then it makes sense to me.

Vlastimil

> - Arnaldo
> 
>> - if it's postprocessing, it would be too late for bpf_get_kmem_cache() as
>> the object might be gone already?
>> 
>> The second alternative would be worse as it could miss the cache or
>> misattribute (in case page is reallocated by another cache), the first is
>> just less efficient than possible.
>> 
>> > +			}
>> > +		}
>> >  
>> >  		err = bpf_map_update_elem(&lock_stat, &key, &first, BPF_NOEXIST);
>> >  		if (err < 0) {