[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202005041112.F3C8117F67@keescook>
Date: Mon, 4 May 2020 11:14:28 -0700
From: Kees Cook <keescook@...omium.org>
To: Pavel Tatashin <pasha.tatashin@...een.com>
Cc: jmorris@...ei.org, sashal@...nel.org, linux-kernel@...r.kernel.org,
pmladek@...e.com, sergey.senozhatsky@...il.com,
rostedt@...dmis.org, anton@...msg.org, ccross@...roid.com,
tony.luck@...el.com, robh+dt@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v1 0/3] allow ramoops to collect all kmesg_dump events
On Sat, May 02, 2020 at 10:35:52AM -0400, Pavel Tatashin wrote:
> Currently, ramoops is capable to collect dmesg buffer only during
> panic and oops events. However, it is desirable for shutdown performance
> analysis reasons to optionally allow collecting dmesg buffers during other
> events as well: reboot, kexec, emergency reboot etc.
>
> How to quickly test:
>
> virtme-run --mods=auto --kdir --mods=auto --kdir . \
> -a memmap=1G$8G -a ramoops.mem_address=0x200000000 \
> -a ramoops.mem_size=0x100000 -a ramoops.record_size=32768 \
> -a ramoops.dump_all=1 -a quiet --qemu-opts -m 8G
> ..
> # reboot -f
>
> After VM is back:
>
> # mount -t pstore pstore /mnt
> # head /mnt/dmesg-ramoops-0
> Restart#1 Part1
Is there a reason that using ramoops.console_size isn't sufficient for
this?
I'm not strictly opposed to making these changes, but traditionally the
granularity of dmesg output has been pretty easily "all or crashes"
instead of a range within.
--
Kees Cook
Powered by blists - more mailing lists