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: <885a9312-484a-4b60-bec0-5adf8f1e4a0e@linaro.org>
Date: Mon, 17 Feb 2025 13:39:39 +0200
From: Eugen Hristev <eugen.hristev@...aro.org>
To: Johannes Berg <johannes@...solutions.net>, 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 2/17/25 13:19, Johannes Berg wrote:
> 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?

Yes, that's why it's marked as an RFC.
> 
>> 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.

Thank you for your feedback.

> 
> johannes