linux-kernel - RE: [RFC PATCH v2 0/3] pmem memmap dump support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <644c17823cf83_13303129460@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Fri, 28 Apr 2023 11:59:14 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Li Zhijian <lizhijian@...itsu.com>, <x86@...nel.org>,
        <nvdimm@...ts.linux.dev>, <kexec@...ts.infradead.org>
CC:     <linux-kernel@...r.kernel.org>, <y-goto@...itsu.com>,
        <yangx.jy@...itsu.com>, <ruansy.fnst@...itsu.com>
Subject: RE: [RFC PATCH v2 0/3] pmem memmap dump support

Li Zhijian wrote:
> Hello folks,
> 
> About 2 months ago, we posted our first RFC[3] and received your kindly feedback. Thank you :)
> Now, I'm back with the code.
> 
> Currently, this RFC has already implemented to supported case D*. And the case A&B is disabled
> deliberately in makedumpfile. It includes changes in 3 source code as below:

I think the reason this patchkit is difficult to follow is that it
spends a lot of time describing a chosen solution, but not enough time
describing the problem and the tradeoffs.

For example why is updating /proc/vmcore with pmem metadata the chosen
solution? Why not leave the kernel out of it and have makedumpfile
tooling aware of how to parse persistent memory namespace info-blocks
and retrieve that dump itself? This is what I proposed here:

http://lore.kernel.org/r/641484f7ef780_a52e2940@dwillia2-mobl3.amr.corp.intel.com.notmuch

...but never got an answer, or I missed the answer.