Linux 6.12 To Optionally Display A QR Code During Kernel Panics

[phoronix]

Phoronix: Linux 6.12 To Optionally Display A QR Code During Kernel Panics

Submitted today via DRM-Misc-Next to DRM-Next for staging ahead of the Linux 6.12 merge window in mid-September is optional support for displaying a QR code within the DRM Panic handler infrastructure when a Linux kernel panic occurs...

https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code

[bug77]

I think I've commented on this before, but is it safe to assume a panicked kernel can still handle the calls for generating a QR code?
(Obviously the answers is yes, otherwise this feature wouldn't have been accepted. I just don't understand how come.)

[schmidtbag]

I think I've commented on this before, but is it safe to assume a panicked kernel can still handle the calls for generating a QR code?
(Obviously the answers is yes, otherwise this feature wouldn't have been accepted. I just don't understand how come.)

I would think that in order for this to work reliably, the instructions to create the code would have to always be present in memory. Seems rather wasteful and unnecessary for something that ideally should never come up.

[dylanmtaylor]

This looks to be incredibly useful.

[bug77]

This looks to be incredibly useful.

It's not like sys admins will a phone handy when they come up across a kernel panic (I'm pretty sure phones are even forbidden in many server rooms), but it doesn't hurt. Unless it panics trying to generate the QR code.

[recyclebin]

I would think that in order for this to work reliably, the instructions to create the code would have to always be present in memory. Seems rather wasteful and unnecessary for something that ideally should never come up.

I don't think missing out on those few extra kilobytes of memory outweights the convenience that this feature brings.

Besides, if it wasn't clear from the title, it's optional. So for any (embedded) systems that are low on memory — that likely will be running a custom configured kernel anyways — can just have it disabled.

Personally, I don't see any negatives here.

[ahrs]

I would think that in order for this to work reliably, the instructions to create the code would have to always be present in memory. Seems rather wasteful and unnecessary for something that ideally should never come up.

We're talking about a couple of extra kilobytes at most. libqrencode is 44K on my system:

$ du -h -s /usr/lib64/libqrencode.so.4.1.1
44K /usr/lib64/libqrencode.so.4.1.1​

That's in userspace, since this is in the kernel it's almost certainly more lightweight than that. The benefit of being able to easily share the QR code with the backtrace encoded rather than having to stitch multiple photos of garbled output together like you do right now far outweighs the negligible extra memory use.

In a fantasy world we don't need this code because the kernel never crashes but back in reality we know it's probably going to crash at some point in some circumstances nobody even considered before or because some hardware is behaving a bit weird, etc.

[ahrs]

It's not like sys admins will a phone handy when they come up across a kernel panic (I'm pretty sure phones are even forbidden in many server rooms), but it doesn't hurt. Unless it panics trying to generate the QR code.

I would guess that these systems have some sort of remote console you can look at instead. It'd be very inconvenient if someone has to drive to the server room and hook up a monitor every time the kernel crashes.

[milkylainen]

This looks to be incredibly useful.

Incredibly. But why stop here?
I can think of a bunch of other post processing to make simple, understandable, portable ascii even more useful...

[ssokolow]

I think I've commented on this before, but is it safe to assume a panicked kernel can still handle the calls for generating a QR code?
(Obviously the answers is yes, otherwise this feature wouldn't have been accepted. I just don't understand how come.)

1. Ever since KMS, the kernel has finally always known the dimensions and pixel format of the framebuffer, so no modesetting code needs to run on panic. (Basically, it can work the same way that UEFI allows your boot to draw the loading animation on top of whatever manufacturer logo your firmware drew.)
2. It's parsing QR codes that's complex. A kernel-mode implementation that just renders them isn't difficult. Hell, it wouldn't surprise me if they already had a solid implementation of Reed-Solomon ECC kicking around somewhere else in the kernel that just needed a once-over to make sure it's core quality, not merely driver quality.