On 2021-04-01, Petr Mladek <pmladek@xxxxxxxx> wrote: >> Caller-id solves this problem and is easy to sort for anyone with >> `grep'. Yes, it is a shame that `dmesg' does not show it, but >> directly using any of the printk interfaces does show it (kmsg_dump, >> /dev/kmsg, syslog, console). > > True but frankly, the current situation is _far_ from convenient: > > + consoles do not show it by default > + none userspace tool (dmesg, journalctl, crash) is able to show it > + grep is a nightmare, especially if you have more than handful of CPUs > > Yes, everything is solvable but not easily. > >> > I get this with "echo l >/proc/sysrq-trigger" and this patchset: >> >> Of course. Without caller-id, it is a mess. But this has nothing to do >> with NMI. The same problem exists for WARN_ON() on multiple CPUs >> simultaneously. If the user is not using caller-id, they are >> lost. Caller-id is the current solution to the interlaced logs. > > Sure. But in reality, the risk of mixed WARN_ONs is small. While > this patch makes backtraces from all CPUs always unusable without > caller_id and non-trivial effort. I would prefer we solve the situation for non-NMI as well, not just for the sysrq "l" case. >> For the long term, we should introduce a printk-context API that allows >> callers to perfectly pack their multi-line output into a single >> entry. We discussed [0][1] this back in August 2020. > > We need a "short" term solution. There are currently 3 solutions: > > 1. Keep nmi_safe() and all the hacks around. > > 2. Serialize nmi_cpu_backtrace() by a spin lock and later by > the special lock used also by atomic consoles. > > 3. Tell complaining people how to sort the messed logs. Or we look into the long term solution now. If caller-id's cannot not be used as the solution (because nobody turns it on, nobody knows about it, and/or distros do not enable it), then we should look at how to make at least the backtraces contiguous. I have a few ideas here. John Ogness _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
