linux-kernel - RE: [PATCH] Drivers: hv: Change flag to write log level in panic msg to false

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <MW2PR2101MB1052E866DA984584B2F8B462D7650@MW2PR2101MB1052.namprd21.prod.outlook.com>
Date:   Fri, 10 Jul 2020 10:10:52 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Olaf Hering <olaf@...fle.de>,
        Joseph Salisbury <Joseph.Salisbury@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>
CC:     "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] Drivers: hv: Change flag to write log level in panic msg
 to false

From: Olaf Hering <olaf@...fle.de>  Sent: Friday, July 10, 2020 2:25 AM
> 
> On Fri, Jun 26, Joseph Salisbury wrote:
> 
> > When the kernel panics, one page worth of kmsg data is written to an allocated
> > page.  The Hypervisor is notified of the page address trough the MSR.  This
> > panic information is collected on the host.  Since we are only collecting one
> > page of data, the full panic message may not be collected.
> 
> Are the people who need to work with this tiny bit of information
> satisfied already, or did they already miss info even with this patch?
> 
> I'm asking because kmsg_dump_get_buffer unconditionally includes the
> timestamp (unless it is enabled). I do wonder if there should be an API
> addition to omit the timestamp. Then even more dmesg output can be
> written into the 4k buffer.
> 

It would be nice to get even more dmesg output into the 4K buffer (or
have a buffer that's bigger than 4K) because there are still occurrences
where we don't get all of the call stack.  But I really don't want to eliminate
the timestamp because it is useful for knowing how long the VM has been
running and to understand what intervals of time there might be between
messages.  I thought about whether parsing the data to keep just the
first timestamp might be a useful compromise, but that seems fairly
messy and I'm not sure it's worth it.  Compressing the kmsg text is
another idea, but the compressed text would probably have problems
getting through our reporting systems.  So we've settled for this small
improvement for now.

Michael