All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: James Morris <jmorris@namei.org>, Sasha Levin <sashal@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	anton@enomsg.org, ccross@android.com,
	Tony Luck <tony.luck@intel.com>,
	robh+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v1 2/3] pstore/ram: allow to dump kmesg during regular reboot
Date: Mon, 4 May 2020 13:54:51 -0700	[thread overview]
Message-ID: <202005041332.0942613D@keescook> (raw)
In-Reply-To: <CA+CK2bDyi-vncYc0_sSZZ9Wb4O7oNUYH-6SN=-XKkeEamB8W8A@mail.gmail.com>

On Mon, May 04, 2020 at 04:30:52PM -0400, Pavel Tatashin wrote:
> > > -static void pstore_register_kmsg(void)
> > > +static void pstore_register_kmsg(int dmesg_all)
> > >  {
> > > +     if (dmesg_all)
> > > +             pstore_dumper.max_reason = KMSG_DUMP_MAX;
> >
> > So, I'd like to avoid any new arguments in the API and instead add a new
> > field to struct pstore_info, which will be valid when PSTORE_FLAGS_DMESG
> > is set, and the max kdump reason can be set there by the pstore backends.
> 
> Hi Kees,
> 
> I am trying to verify that I understand the request correctly:
> 
> 1. pstore_register_kmsg() -> remove argument.

Yes (or, from the perspective of what v2 will look like, "do not add
an argument to pstore_register_kmsg()").

> 2. pstore_info -> add a new field  max_kmsg_reason: contains the
> actual reason value

Let's just call it max_reason, but yes. And perhaps instead of adding
KMSG_DUMP_MAX, maybe just use INT_MAX or something for "all reasons".

> 3. Modify: pstore_register() to set this field in pstore_dumper prior
> to calling pstore_register_kmsg().

Correct.

> 4. remove ramoops.dump_all boolean parameter

Yes, or more specifically, "don't add ramoops.dump_all".

> 5. add a new parameter ramoops.max_reason integer variable, which will
> be set in pstore_register_kmsg

Right, though this will likely require some refactoring of the existing
handling of the dump_oops parameter, likely as a separate patch, since
we should not remove the parameter, as some systems may be expecting to
use it still. But it should be reworked in terms of the new max_reason.

> 6. Modify other users of pstore_register() to provide the correct
> max_kmsg_reason.

Yes, which should be a trivial adjustment. You can look for all the
initializers using PSTORE_FLAGS_DMESG:

arch/powerpc/kernel/nvram_64.c: .flags = PSTORE_FLAGS_DMESG,
drivers/acpi/apei/erst.c:       .flags          = PSTORE_FLAGS_DMESG,
drivers/firmware/efi/efi-pstore.c:      .flags          = PSTORE_FLAGS_DMESG,

It looks like all the other backends actually already dump all reasons,
so they should likely all be set to the INT_MAX, or whatever is chosen
for "all reasons".

> 
> Is this correct?

But, yes, your list essentially matches what I've got in my head too. :)

-- 
Kees Cook

  reply	other threads:[~2020-05-04 20:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02 14:35 [PATCH v1 0/3] allow ramoops to collect all kmesg_dump events Pavel Tatashin
2020-05-02 14:35 ` [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper Pavel Tatashin
2020-05-04 17:15   ` Steven Rostedt
2020-05-04 17:56     ` Pavel Tatashin
2020-05-04 18:12     ` Kees Cook
2020-05-04 18:40       ` Pavel Tatashin
2020-05-05  1:02   ` Sergey Senozhatsky
2020-05-05  2:52     ` Pavel Tatashin
2020-05-05  3:12       ` Pavel Tatashin
2020-05-05  4:21         ` Pavel Tatashin
2020-05-05 10:50           ` Sergey Senozhatsky
2020-05-02 14:35 ` [PATCH v1 2/3] pstore/ram: allow to dump kmesg during regular reboot Pavel Tatashin
2020-05-04 19:29   ` Kees Cook
2020-05-04 20:30     ` Pavel Tatashin
2020-05-04 20:54       ` Kees Cook [this message]
2020-05-02 14:35 ` [PATCH v1 3/3] ramoops: add dump_all optional field to ramoops DT node Pavel Tatashin
2020-05-04 19:29   ` Kees Cook
2020-05-04 20:00     ` Pavel Tatashin
2020-05-05 15:14       ` Pavel Tatashin
2020-05-04 18:14 ` [PATCH v1 0/3] allow ramoops to collect all kmesg_dump events Kees Cook
2020-05-04 18:47   ` Pavel Tatashin
2020-05-04 19:12     ` Kees Cook
2020-05-04 19:17       ` Pavel Tatashin
2020-05-04 19:30         ` Kees Cook
2020-05-04 20:00           ` Pavel Tatashin
2020-05-05 12:36         ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202005041332.0942613D@keescook \
    --to=keescook@chromium.org \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=pmladek@suse.com \
    --cc=robh+dt@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sashal@kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.