On Monday, December 30th, 2024 at 10:37 AM, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
>
>
> On Mon, Dec 30, 2024 at 01:11:41PM -0300, Arnaldo Carvalho de Melo wrote:
>
> > > Not really :-\
> > >
> > > root@number:/home/acme/git/pahole# pfunct --decl_info -F dwarf evtchn_fifo_is_pending /lib/modules/6.13.0-rc2/build/vmlinux
> > > /* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c /
> > > / <946502e> /home/acme/git/linux/drivers/xen/events/events_fifo.c:206 /
> > > bool evtchn_fifo_is_pending(evtchn_port_t port);
> > > / Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c /
> > > / <946502e> /home/acme/git/linux/drivers/xen/events/events_fifo.c:206 */
> > > bool evtchn_fifo_is_pending(evtchn_port_t port);
> > > root@number:/home/acme/git/pahole#
> > >
> > > So far I couldn't find an explanation for this oddity... Lets see if
> > > after applying all patches we get past this.
>
> > Its not related to this patch series, before we get two outputs for
> > these (and other functions in
> > /home/acme/git/linux/drivers/xen/events/events_fifo.c).
> >
> > Still investigating.
>
>
> root@number:/home/acme/git/pahole# perf probe -x ~/bin/pfunct function__show
> Added new event:
> probe_pfunct:function_show (on function__show in /home/acme/git/pahole/build/pfunct)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_pfunct:function_show -aR sleep 1
>
> root@number:/home/acme/git/pahole# perf trace -e probe_pfunct:function_show --call-graph dwarf pfunct --decl_info -F dwarf evtchn_fifo_set_pending /lib/modules/6.13.0-rc2/build/vmlinux
> /* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c /
> / <946517a> /home/acme/git/linux/drivers/xen/events/events_fifo.c:200 */
>
> void evtchn_fifo_set_pending(evtchn_port_t port);
> /* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c /
> / <946517a> /home/acme/git/linux/drivers/xen/events/events_fifo.c:200 */
>
> void evtchn_fifo_set_pending(evtchn_port_t port);
> 0.000 pfunct/2006089 probe_pfunct:function_show(__probe_ip: 4208235)
> function__show (/home/acme/git/pahole/build/pfunct)
> pfunct_stealer (/home/acme/git/pahole/build/pfunct)
> cus__steal_now (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
> dwarf_loader__worker_thread (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
> start_thread (/usr/lib64/libc.so.6)
> clone3 (/usr/lib64/libc.so.6)
> 0.134 pfunct/2006088 probe_pfunct:function_show(__probe_ip: 4208235)
> function__show (/home/acme/git/pahole/build/pfunct)
> cu_function_iterator (/home/acme/git/pahole/build/pfunct)
> cus__for_each_cu (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
> main (/home/acme/git/pahole/build/pfunct)
> __libc_start_call_main (/usr/lib64/libc.so.6)
> __libc_start_main@@GLIBC_2.34 (/usr/lib64/libc.so.6)
> _start (/home/acme/git/pahole/build/pfunct)
> root@number:/home/acme/git/pahole#
>
> With the following patch we get just one output for this case, but that
> isn't the right solution... I'll look on removing the
> cu_function_iterator() based printing, otherwise when printing all
> matches we'll still duplicate the printings.
>
> Anyway, doesn't seem related to the problem that tests/tests was
> catching, that I'm not being able to reproduce anymore after having the
> whole series applied, probably some race?
Hi Arnaldo, thank you for testing.
I couldn't reproduce the mismatch error that you saw:
root@number:/home/acme/git/pahole# tests/tests
1: Validation of BTF encoding of functions; this may take some time: grep: /tmp/btf_functions.sh.OgxoO4/dwarf.funcs: binary file matches
ERROR: mismatch : BTF 'bool evtchn_fifo_is_pending(evtchn_port_t);' not found; DWARF ''
Test data is in /tmp/btf_functions.sh.OgxoO4
I've tried a couple of kernels:
* 6.12 with selftests/bpf config
* Fedora 6.12.6-100.fc40.x86_64 (my workstation)
* 6.13-rc2 with Fedora-like config
I saw warnings that don't seem to be related to this series:
theihor@qube:~/dev/dwarves$ PATH=$(realpath build):$PATH vmlinux=~/git/kernel.org/linux-for-pahole/vmlinux ./tests/tests
1: Validation of BTF encoding of functions; this may take some time: Ok
2: Default BTF on a system without BTF: Ok
3: Flexible arrays accounting: WARNING: still unsuported BTF_KIND_DECL_TAG(bpf_fastcall) for bpf_cast_to_kern_ctx already with attribute (bpf_kfunc), ignoring
WARNING: still unsuported BTF_KIND_DECL_TAG(bpf_fastcall) for bpf_rdonly_cast already with attribute (bpf_kfunc), ignoring
Ok
4: Pretty printing of files using DWARF type information: Ok
5: Parallel reproducible DWARF Loading/Serial BTF encoding: Ok
As for potential race, since btf_encoder is sequential and a unit of
work is a CU, I don't see how a single function could have been
missed. Other declarations in events_fifo.c would've been affected I
think.
If you see this again, please let me know.
>
> - Arnaldo
>
> diff --git a/pfunct.c b/pfunct.c
> index 55eafe8a8e790dcb..9645b004381a7e1e 100644
> --- a/pfunct.c
> +++ b/pfunct.c
> @@ -518,7 +518,13 @@ static enum load_steal_kind pfunct_stealer(struct cu *cu,
>
> if (tag) {
> function__show(tag__function(tag), cu);
> - return show_all_matches ? LSK__DELETE : LSK__STOP_LOADING;
> + if (!show_all_matches) {
> + // Expedite exit, since we already did what was requested:
> + // print the first occurrence of a given function
> + exit(0);
> + }
> +
> + return LSK__DELETE;
> }
> } else if (class_name) {
> cu_class_iterator(cu, class_name);
