Searched hist:b1f6f161 (Results 1 – 2 of 2) sorted by relevance
/linux/include/linux/ |
H A D | kmsg_dump.h | b1f6f161 Tue May 05 15:45:06 GMT 2020 Pavel Tatashin <pasha.tatashin@soleen.com> printk: honor the max_reason field in kmsg_dumper
kmsg_dump() allows to dump kmesg buffer for various system events: oops, panic, reboot, etc. It provides an interface to register a callback call for clients, and in that callback interface there is a field "max_reason", but it was getting ignored when set to any "reason" higher than KMSG_DUMP_OOPS unless "always_kmsg_dump" was passed as kernel parameter.
Allow clients to actually control their "max_reason", and keep the current behavior when "max_reason" is not set.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/lkml/20200515184434.8470-3-keescook@chromium.org/ Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Kees Cook <keescook@chromium.org>
|
/linux/kernel/printk/ |
H A D | printk.c | b1f6f161 Tue May 05 15:45:06 GMT 2020 Pavel Tatashin <pasha.tatashin@soleen.com> printk: honor the max_reason field in kmsg_dumper
kmsg_dump() allows to dump kmesg buffer for various system events: oops, panic, reboot, etc. It provides an interface to register a callback call for clients, and in that callback interface there is a field "max_reason", but it was getting ignored when set to any "reason" higher than KMSG_DUMP_OOPS unless "always_kmsg_dump" was passed as kernel parameter.
Allow clients to actually control their "max_reason", and keep the current behavior when "max_reason" is not set.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/lkml/20200515184434.8470-3-keescook@chromium.org/ Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Kees Cook <keescook@chromium.org>
|