[BUG] tracing: Too many tries to read user space
From: Jeongho Choi
Date: Wed Jul 08 2026 - 08:39:20 EST
Hello,
We are seeing a reproducible kernel panic related to the tracing code
when it fails to read user-space memory.
The issue was originally reported through the Android/Google Issue
Tracker, and we were advised to report it to the upstream trace mailing
list because the affected code is upstream.
Environment:
Architecture: arm64
Kernel: Linux 6.18.21
Base: Android Common Kernel (android17-6.18)
Affected area: kernel/trace/
The relevant error/panic log is:
[48916.569148] [9: lmkd: 536] Error: Too many tries to read
user space
[48916.569156] [9: lmkd: 536] WARNING: CPU: 9 PID: 536 at
kernel/trace/trace.c:7374 trace_user_fault_read+0x334/0x360
[48916.569443] [9: lmkd: 536] CPU: 9 UID: 1069 PID: 536 Comm:
lmkd Tainted: G OE 6.18.21-android17-5-ga1a8e8cab9ec-4k
#1 PREEMPT 25372cd4750dcac3c0fe86b57d47c665f97a6046
[48916.569450] [9: lmkd: 536] pstate: 63402005 (nZCv daif
+PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[48916.569452] [9: lmkd: 536] pc :
trace_user_fault_read+0x334/0x360
[48916.569454] [9: lmkd: 536] lr :
trace_user_fault_read+0x330/0x360
[48916.569456] [9: lmkd: 536] sp : ffffffc096993cc0
[48916.569457] [9: lmkd: 536] x29: ffffffc096993cd0 x28:
0000000000000065 x27: ffffff8817e45200
[48916.569461] [9: lmkd: 536] x26: 0000000000000000 x25:
000000011616c082 x24: 0000000000000000
[48916.569463] [9: lmkd: 536] x23: 0000000000000009 x22:
000000000000002b x21: ffffff880597f740
[48916.569466] [9: lmkd: 536] x20: 0000007fc42dd940 x19:
ffffff8817e45770 x18: ffffffd5947ce240
[48916.569468] [9: lmkd: 536] x17: 2073656972742079 x16:
6e616d206f6f5420 x15: 3a726f727245205d
[48916.569471] [9: lmkd: 536] x14: 36333520203a646b x13:
6563617073207265 x12: 0000000000000001
[48916.569473] [9: lmkd: 536] x11: 6f74207365697274 x10:
0000000000000001 x9 : 4bd9ad4516d75100
[48916.569476] [9: lmkd: 536] x8 : 4bd9ad4516d75100 x7 :
205d383431393635 x6 : 2e36313938345b0a
[48916.569479] [9: lmkd: 536] x5 : ffffffc080fa5998 x4 :
ffffffd591707202 x3 : 0001360a00000000
[48916.569481] [9: lmkd: 536] x2 : ffffffc096993af4 x1 :
00000000000000c0 x0 : 0000000000000028
[48916.569484] [9: lmkd: 536] Call trace:
[48916.569486] [9: lmkd: 536]
trace_user_fault_read+0x334/0x360 (P)
[48916.569488] [9: lmkd: 536] tracing_mark_write+0x84/0x174
[48916.569491] [9: lmkd: 536] __arm64_sys_write+0x2a0/0x5c0
[48916.569494] [9: lmkd: 536] invoke_syscall+0x58/0xe4
[48916.569498] [9: lmkd: 536] do_el0_svc+0x48/0xdc
[48916.569500] [9: lmkd: 536] el0_svc+0x3c/0x98
[48916.569503] [9: lmkd: 536]
el0t_64_sync_handler+0x20/0x130
[48916.569505] [9: lmkd: 536] el0t_64_sync+0x1c4/0x1c8
[48916.569508] [9: lmkd: 536] Kernel panic - not syncing:
kernel: panic_on_warn set ...
The code at the WARN location mentioned in the log above is as follows.
7374 if (WARN_ONCE(trys++ > 100, "Error: Too many
tries to read user space"))
7375 return NULL;
Our current analysis is as follows:
In the Gmail process, during a low memory situation, LMKD writes strings
to /sys/kernel/tracing/trace_marker for systrace recording. At the same
time, it broadcasts a sigkill due to low memory, which is causing the
LMKD trace marker operation to stall.
Please review this issue.
Thanks,
Jeongho Choi