On Wed, 8 Jul 2026 09:18:04 -0400 Steven Rostedt <[email protected]> wrote:
> On Wed, 8 Jul 2026 21:37:53 +0900 > Jeongho Choi <[email protected]> wrote: > > > 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; > > > > This happens when something forces a schedule. > > > > > 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. > > > > Can you see what is being scheduled in? Perhaps use the persistent ring > buffer (if you can) and enable sched_switch tracepoint in it. Nit: If the device just caused oom and not crash/reboot the kernel, you can just use normal ring buffer (or perfetto). Thanks, -- Masami Hiramatsu (Google) <[email protected]>
