Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-05 Thread Sergey Senozhatsky
On (20/05/05 00:21), Pavel Tatashin wrote: > > > I changed it to make code cleaner: for such basic operation there are > > > too many conditions if we will keep it inside the kmsg_dump(). > > > However, if being able to set always_kmsg_dump dynamically during > > > runtime is deemed important, I

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Pavel Tatashin
> > I changed it to make code cleaner: for such basic operation there are > > too many conditions if we will keep it inside the kmsg_dump(). > > However, if being able to set always_kmsg_dump dynamically during > > runtime is deemed important, I can change it back to be checked in > > kmsg_dump.

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Pavel Tatashin
On Mon, May 4, 2020 at 10:52 PM Pavel Tatashin wrote: > > > > @@ -3157,12 +3162,9 @@ void kmsg_dump(enum kmsg_dump_reason reason) > > > struct kmsg_dumper *dumper; > > > unsigned long flags; > > > > > > - if ((reason > KMSG_DUMP_OOPS) && !always_kmsg_dump) > > > -

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Pavel Tatashin
> > @@ -3157,12 +3162,9 @@ void kmsg_dump(enum kmsg_dump_reason reason) > > struct kmsg_dumper *dumper; > > unsigned long flags; > > > > - if ((reason > KMSG_DUMP_OOPS) && !always_kmsg_dump) > > - return; > > - > > rcu_read_lock(); > >

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Sergey Senozhatsky
On (20/05/02 10:35), Pavel Tatashin wrote: [..] > +static bool always_kmsg_dump; > +module_param_named(always_kmsg_dump, always_kmsg_dump, bool, S_IRUGO | > S_IWUSR); > > /** > * kmsg_dump_register - register a kernel log dumper. > @@ -3106,6 +3108,12 @@ int kmsg_dump_register(struct

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Pavel Tatashin
Thank Kees, I think it is a little cleaner this way. Thank you, Pasha On Mon, May 4, 2020 at 2:12 PM Kees Cook wrote: > > On Mon, May 04, 2020 at 01:15:00PM -0400, Steven Rostedt wrote: > > On Sat, 2 May 2020 10:35:53 -0400 > > Pavel Tatashin wrote: > > > > > kmsg_dump() allows to dump kmesg

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Kees Cook
On Mon, May 04, 2020 at 01:15:00PM -0400, Steven Rostedt wrote: > On Sat, 2 May 2020 10:35:53 -0400 > Pavel Tatashin wrote: > > > 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

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Pavel Tatashin
> Hmm, I didn't realize that enums were allowed to have duplicates. That can > usually screw up logic. I would recommend making that a define afterward. > > #define KMSG_DUMP_MAX KMSG_DUMP_POWEROFF > > As is done in other locations of the kernel. > Hi Steve, Sure, I will change it to define.

Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-04 Thread Steven Rostedt
On Sat, 2 May 2020 10:35:53 -0400 Pavel Tatashin wrote: > 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" > which gets

[PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper

2020-05-02 Thread Pavel Tatashin
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" which gets ignored unless always_kmsg_dump is passed as kernel parameter.