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

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]

On Mon, Sep 08, 2025 at 10:55:17AM +0200, Jocelyn Falempe wrote:
> On 03/09/2025 10:19, Maxime Ripard wrote:
> > On Wed, Sep 03, 2025 at 09:30:23AM +0200, Jocelyn Falempe wrote:
> > > 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,
> > 
> > We also have to think about how it's going to be shipped and used. If
> > your debugfs integration has to be disabled everytime we're running
> > kunit through uml, qemu, and in CI (because we can't retrieve the
> > result), on a live system (because it would leak memory indefinitely),
> > how is it useful?
> 
> There is already a kconfig for this:
> CONFIG_DRM_PANIC_DEBUG
> 
> Also I have an implementation that doesn't leak memory. (memory is freed
> when the debugfs file is closed).

So, if userspace completely ignores it, you still leak it.

> It's also more flexible, as you can change the parameters, and test any
> color format, and check the binary result.
>
> I think the goal of this is not to test for regression, but to help building
> a new panic screen.
> 
> > 
> > The diagnostic lines are part of the test result, are in the logs, and
> > can be distributed. You're having all those problems solved already,
> > without having any additional work to do.
> 
> I feel sending an image through log is not really efficient, and I don't
> want to pollute all the CI with that.

Then maybe we should just ignore that part of your series for now. But
having a framebuffer lingering around in the system is a no-go for me.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]