linux-kernel - Re: [BUG] perf segfaults when combining --overwrite and intel

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: <CAP4=nvQ_7oS5ZAsKmOd_ORg0tyHS=B+i2m63K=TLg22rTEiRGQ@mail.gmail.com>
Date: Mon, 28 Apr 2025 12:45:41 +0200
From: Tomas Glozar <tglozar@...hat.com>
To: Leo Yan <leo.yan@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, linux-perf-users@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>, Wander Costa <wcosta@...hat.com>
Subject: Re: [BUG] perf segfaults when combining --overwrite and intel_pt event

po 28. 4. 2025 v 12:22 odesílatel Leo Yan <leo.yan@....com> napsal:
>
> Hi Tomas,
>

Hi Leo,

> I would like to suggest a fix blow.  For overwrite mode, we need a
> fixup to remap the user page with write permission.
>
> Could you confirm if works at you side?
>

Thank you for looking at this. The initial segfault on writing to
read-only page is fixed, however, perf now segfaults in a different
place:

(gdb) r
Starting program: /home/tglozar/dev/linux/tools/perf/perf record
--overwrite -a -e intel_pt/cyc,noretcomp/k sleep 5
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 424037]
[New Thread 0x7ffff2df46c0 (LWP 424038)]
[ perf record: Woken up 1 times to write data ]
Thread 1 "perf" received signal SIGSEGV, Segmentation fault.
intel_pt_info_fill (itr=0x7a1e40, session=0x794ef0,
auxtrace_info=0x7cdfd0, priv_size=144) at arch/x86/util/intel-pt.c:361
361             pc = session->evlist->mmap[0].core.base;
(gdb) bt
#0  intel_pt_info_fill (itr=0x7a1e40, session=0x794ef0,
auxtrace_info=0x7cdfd0, priv_size=144) at arch/x86/util/intel-pt.c:361
#1  0x000000000061ce76 in auxtrace_record__info_fill (itr=0x7a1e40,
session=0x794ef0, auxtrace_info=0x7cdfd0, priv_size=144)
   at util/auxtrace.c:580
#2  0x000000000061ec48 in perf_event__synthesize_auxtrace_info
(itr=0x7a1e40, tool=0x765de0 <record>, session=0x794ef0,
   process=0x41a747 <process_synthesized_event>) at util/auxtrace.c:1320
#3  0x000000000041e869 in record__synthesize (rec=0x765de0 <record>,
tail=true) at builtin-record.c:2062
#4  0x0000000000420d04 in __cmd_record (rec=0x765de0 <record>, argc=2,
argv=0x7fffffffe0e0) at builtin-record.c:2841
#5  0x0000000000424025 in cmd_record (argc=2, argv=0x7fffffffe0e0) at
builtin-record.c:4285
#6  0x0000000000461143 in run_builtin (p=0x76a260 <commands+288>,
argc=7, argv=0x7fffffffe0e0) at perf.c:351
#7  0x00000000004613b2 in handle_internal_command (argc=7,
argv=0x7fffffffe0e0) at perf.c:404
#8  0x0000000000461501 in run_argv (argcp=0x7fffffffdecc,
argv=0x7fffffffdec0) at perf.c:448
#9  0x00000000004617e7 in main (argc=7, argv=0x7fffffffe0e0) at perf.c:556
(gdb) p session->evlist->mmap
$2 = (struct mmap *) 0x0

This appears to be a different bug.

Tomas