linux-kernel - Re: [RFC][PATCH 00/10] pstore: directly mapped regions

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: <59333d4aa8a3bb3222967d70d10d9288cece444c.camel@sipsolutions.net>
Date: Mon, 17 Feb 2025 12:19:15 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Eugen Hristev <eugen.hristev@...aro.org>, linux-arm-msm@...r.kernel.org,
 	linux-hardening@...r.kernel.org, kees@...nel.org
Cc: linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
 rafael@...nel.org, 	dakr@...nel.org, andersson@...nel.org,
 konradybcio@...nel.org, tony.luck@...el.com, 	gpiccoli@...lia.com,
 pmladek@...e.com, rostedt@...dmis.org, 	john.ogness@...utronix.de,
 senozhatsky@...omium.org, quic_mojha@...cinc.com, 
	linux-arm-kernel@...ts.infradead.org, kernel@...cinc.com
Subject: Re: [RFC][PATCH 00/10] pstore: directly mapped regions

On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
> 
> At this moment going through devcoredump is not something that impacts
> the idea of the implementation.

Yeah. I don't think it _should_ go through it at all.

> The whole reason of going through it (because things work without it as
> well), is to see whether this has any kind of impact or not, and if
> there is any kind of fit/reason of going through it.

So it's just a trial balloon?

> Devcoredump is involved because the whole core registration is similar
> to a core area that devcoredump could use.

Yeah but ... 

> For example, would it be interesting to have a handler going through all
> devices, and have the dump areas already registered ?
> Meaning, when there is a request to generate a core dump, one could
> directly dump this area instead of calling back the driver, and provide
> that to the userspace instead of the driver calling the dev_coredumpv by
> its own.

I'll be blunt ... so you _really_ haven't understood devcoredump then?

It's really not doing this. It's not meant to do this... It's intended
to dump data from inside the device when the device crashes.

Please remove devcoredump involvement from this series.

johannes