On Tue 2018-04-24 10:33:36, Sergey Senozhatsky wrote: > Yes, Tetsuo, we use a bunch of "printk prefix" extensions at Samsung. > For instance, we prefix printk messages with the CPU number: messages > sometimes mix up, we also see partial pr_cont flushes, and so on. > Grep-ping serial logs by CPU number is quite powerful. > > Upstreaming those printk prefixes can be a bit challenging, but may > be it's not all so bad. I personally think that syzbot, and build-test > bots in general [like 0day], are helpful indeed, and I don't see why life > should be any more complex for syzbot/0day guys. If printk prefixes can > help - then we probably should consider such an extension. > > The main argument from the upstream is that tweaking struct printk_log > breaks user space (tools like crash, and so on). But I guess we can do > something about it. E.g. put a PRINTK_CONTEXT_TRACKING_PREFIX kconfig > option somewhere in "Kernel hacking"->"printk and dmesg options" and > make available only for DEBUG kernels, or something similar.
> Petr, Steven, Fengguang, what do you think? Do you have any objections? > Ideas? I wonder if we could create some mechanism that would help to extend struct printk_log easier in the future. I know only about crash tool implementation. It uses information provided by log_buf_vmcoreinfo_setup(). The size of the structure is already public. Therefore crash should be able to find all existing information even if we increase the size of the structure. log_buf_vmcoreinfo_setup() even allows to inform about newly added structure items. We could probably extend it to inform also about the offset of the new optional elements. I am not sure about other tools. But I think that it should be doable. Best Regards, Petr