From: Kees Cook <keescook@chromium.org>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: jmorris@namei.org, sashal@kernel.org,
linux-kernel@vger.kernel.org, pmladek@suse.com,
sergey.senozhatsky@gmail.com, rostedt@goodmis.org,
anton@enomsg.org, ccross@android.com, tony.luck@intel.com,
robh+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/5] pstore/platform: pass max_reason to kmesg dump
Date: Tue, 5 May 2020 14:59:37 -0700 [thread overview]
Message-ID: <202005051444.14B6686@keescook> (raw)
In-Reply-To: <20200505154510.93506-3-pasha.tatashin@soleen.com>
On Tue, May 05, 2020 at 11:45:07AM -0400, Pavel Tatashin wrote:
> Add a new field to pstore_info that passes information about kmesg dump
> maximum reason.
>
> This allows a finer control of what kmesg dumps are stored on pstore
> device.
>
> Those clients that do not explicitly set this field (keep it equal to 0),
> get the default behavior: dump only Oops and Panics, and dump everything
> if printk.always_kmsg_dump is provided.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> fs/pstore/platform.c | 4 +++-
> include/linux/pstore.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 408277ee3cdb..75bf8a43f92a 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -602,8 +602,10 @@ int pstore_register(struct pstore_info *psi)
> if (pstore_is_mounted())
> pstore_get_records(0);
>
> - if (psi->flags & PSTORE_FLAGS_DMESG)
> + if (psi->flags & PSTORE_FLAGS_DMESG) {
> + pstore_dumper.max_reason = psinfo->max_reason;
> pstore_register_kmsg();
> + }
I haven't finished reading the whole series carefully, but I think
something we can do here to make things a bit more user-friendly is to
do the KMSG_DUMP_UNDEF value here to get us the "all" instead of INT_MAX:
if (psi->flags & PSTORE_FLAGS_DMESG) {
pstore_dumper.max_reason = psinfo->max_reason;
if (pstore_dumper.max_reason == KMSG_DUMP_UNDEF)
pstore_dumper.max_reason = KMSG_DUMP_MAX;
pstore_register_kmsg();
}
That way setting max_reason to 0 without setting dump_oops at all will
get "all". I think it'll need some tweaks to the next patch.
> if (psi->flags & PSTORE_FLAGS_CONSOLE)
> pstore_register_console();
> if (psi->flags & PSTORE_FLAGS_FTRACE)
> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
> index e779441e6d26..45ae424bfeb5 100644
> --- a/include/linux/pstore.h
> +++ b/include/linux/pstore.h
> @@ -97,6 +97,8 @@ struct pstore_record {
> * @read_mutex: serializes @open, @read, @close, and @erase callbacks
> * @flags: bitfield of frontends the backend can accept writes for
> * @data: backend-private pointer passed back during callbacks
> + * @max_reason: Used when PSTORE_FLAGS_DMESG is set. Contains the
> + * kmsg_dump_reason enum value.
Nit: please move this above @data since it has a @flags dependency.
> *
> * Callbacks:
> *
> @@ -180,6 +182,7 @@ struct pstore_info {
>
> int flags;
> void *data;
> + int max_reason;
>
> int (*open)(struct pstore_info *psi);
> int (*close)(struct pstore_info *psi);
> --
> 2.25.1
>
Looking good!
--
Kees Cook
next prev parent reply other threads:[~2020-05-05 21:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 15:45 [PATCH v2 0/5] allow ramoops to collect all kmesg_dump events Pavel Tatashin
2020-05-05 15:45 ` [PATCH v2 1/5] printk: honor the max_reason field in kmsg_dumper Pavel Tatashin
2020-05-14 8:49 ` Petr Mladek
2020-05-05 15:45 ` [PATCH v2 2/5] pstore/platform: pass max_reason to kmesg dump Pavel Tatashin
2020-05-05 21:59 ` Kees Cook [this message]
2020-05-06 13:52 ` Steven Rostedt
2020-05-06 14:31 ` Pavel Tatashin
2020-05-06 14:42 ` Pavel Tatashin
2020-05-05 15:45 ` [PATCH v2 3/5] pstore/ram: in ramoops_platform_data convert dump_oops to max_reason Pavel Tatashin
2020-05-05 23:15 ` Kees Cook
2020-05-06 13:42 ` Pavel Tatashin
2020-05-05 15:45 ` [PATCH v2 4/5] pstore/ram: allow to dump kmesg during regular reboot Pavel Tatashin
2020-05-05 15:45 ` [PATCH v2 5/5] ramoops: add max_reason optional field to ramoops DT node Pavel Tatashin
2020-05-13 2:42 ` Rob Herring
2020-05-13 14:21 ` Kees Cook
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=202005051444.14B6686@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).