linux-kernel - Re: [PATCH 3/3] drm/panic: Add a kconfig option to dump kunits results to png

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: <533c2197-d7bb-4294-a094-c4f993a5893c@redhat.com>
Date: Wed, 3 Sep 2025 09:30:23 +0200
From: Jocelyn Falempe <jfalempe@...hat.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Javier Martinez Canillas <javierm@...hat.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 3/3] drm/panic: Add a kconfig option to dump kunits
 results to png

On 02/09/2025 18:58, Maxime Ripard wrote:
> On Mon, Sep 01, 2025 at 03:04:26PM +0200, Jocelyn Falempe wrote:
>> On 27/08/2025 12:45, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 21.08.25 um 11:49 schrieb Jocelyn Falempe:
>>>> This is a bit hacky, but very handy if you want to customize the
>>>> panic screen.
>>>> It allows to dump the generated images to the logs, and then a python
>>>> script can convert it to .png files. It makes it easy to check how
>>>> the panic screen will look on different resolutions, without having
>>>> to crash a VM.
>>>> To not pollute the logs, it uses a monochrome framebuffer, compress
>>>> it with zlib, and base64 encode it.
>>>
>>> May I suggest to export the raw image via debugfs? Debugfs can also
>>> export additional information in additional files, such as width/height/
>>> stride/format. This could provide the real/last image on the fly, simply
>>> by reading the files. No workarounds or encodings needed.
>>
>> I'm looking into that. The difficulty is to get the debugfs content outside
>> of the test kernel. As I'm using a uml kernel for testing, I will need a
>> special initrd, and a way to share files with the host.
> 
> Yeah, I agree that it's not very practical. If only because the test
> context doesn't stick around once it's been executed, so you would
> effectively leak an arbritrarily long buffer with no hope of getting
> back its memory.

I've made a prototype with debugfs, a small ramdisk with busybox, and 
using hostfs to mount the host filesystem in the uml kernel, and it 
allows to dump the raw panic buffer easily.
Even if it's a bit more complex to setup, I think this use case is not 
really a kunit test, so it's probably better that way.

Let me a few days to clean that up, and I will send a v2 of the kunit 
tests, and a new series to add a debugfs interface.

Thanks for your reviews,

-- 

Jocelyn

> 
> Maxime