[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+CK2bAF+cS_H-tU29wE54tsdRnBvBEpewgQ7ZM7BfLhASV1mg@mail.gmail.com>
Date: Mon, 4 May 2020 14:40:49 -0400
From: Pavel Tatashin <pasha.tatashin@...een.com>
To: Kees Cook <keescook@...omium.org>
Cc: Steven Rostedt <rostedt@...dmis.org>,
James Morris <jmorris@...ei.org>,
Sasha Levin <sashal@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
anton@...msg.org, ccross@...roid.com,
Tony Luck <tony.luck@...el.com>, robh+dt@...nel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper
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 <keescook@...omium.org> 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 <pasha.tatashin@...een.com> 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 ignored unless always_kmsg_dump is passed as kernel parameter.
> > >
> > > Allow clients to decide max_reason, and keep the current behavior when
> > > max_reason is not set.
> > >
> > > Signed-off-by: Pavel Tatashin <pasha.tatashin@...een.com>
> > > ---
> > > include/linux/kmsg_dump.h | 1 +
> > > kernel/printk/printk.c | 16 +++++++++-------
> > > 2 files changed, 10 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
> > > index 2e7a1e032c71..c0d703b7ce38 100644
> > > --- a/include/linux/kmsg_dump.h
> > > +++ b/include/linux/kmsg_dump.h
> > > @@ -28,6 +28,7 @@ enum kmsg_dump_reason {
> > > KMSG_DUMP_RESTART,
> > > KMSG_DUMP_HALT,
> > > KMSG_DUMP_POWEROFF,
> > > + KMSG_DUMP_MAX = KMSG_DUMP_POWEROFF
> >
> > 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.
>
> I've seen it also be the last item in an enum, then comparisons can just
> do "< KMSG_DUMP_MAX" instead of "<= KMSG_DUMP_MAX".
>
> --
> Kees Cook
Powered by blists - more mailing lists