Hi, On Fri, 12 Dec 2025 at 12:46, Nicolas Frattaroli <[email protected]> wrote: > On Thursday, 11 December 2025 23:38:22 Central European Standard Time David > Laight wrote: > > Except that all the systems with PANIC_ON_WARN set will panic. > > I believe that is somewhere over 90% of systems. > > I also like making up statistics. Warning here is the correct move > in my opinion because this warning being triggered indicates a bug > in the kernel code, and with PANIC_ON_WARN the user explicitly says > they would rather panic in such a case than treat it as an abnormal > condition that is recoverable. > > The reason why this condition ever occurring should be treated as an > abnormal condition is because the DRM subsystem should guarantee we > don't get a framebuffer of a format we didn't explicitly declare > support for in the first place. So this condition being hit either > means drm_universal_plane_init is broken, or the array of formats > that's passed to it is out of sync with the conversion code, which > is also a bug. Or someone managed to thoroughly hose DRM's internal > kernel-side data structures, which is precisely the kind of thing > PANIC_ON_WARN users want to abort for.
Yes, that's exactly it. We make all kinds of load-bearing assumptions everywhere: that PM code won't pass in a NULL struct device pointer to the resume handler, that our driver callbacks won't get called whilst the device is runtime-suspended, etc. We could try to handle every single one of those with if (clk == NULL) return 0; /* ??? */, or we could not. If you'd like, we could just delete every one of these checks and replace them with comments, explaining what we assume the invariants to be, and wait for an OOPS due to dereferencing invalid pointers. But the MISRA style of 'handling' every possible impossible case is not tractable. Cheers, Daniel
