Am Montag, 20. Oktober 2025, 15:47:16 Mitteleuropäische Sommerzeit schrieb Daniel Stone: > Hi, > > On Mon, 20 Oct 2025 at 14:25, Heiko Stuebner <[email protected]> wrote: > > Am Montag, 20. Oktober 2025, 15:10:31 Mitteleuropäische Sommerzeit schrieb > > Heiko Stuebner: > > > Am Mittwoch, 15. Oktober 2025, 13:00:35 Mitteleuropäische Sommerzeit > > > schrieb Daniel Stone: > > > > format = vop2_convert_format(fb->format->format); > > > > - if (format < 0) > > > > - return format; > > > > + /* We shouldn't be able to create a fb for an unsupported format */ > > > > + WARN_ON(format < 0); > > > > > > What happened to Greg's > > > "But don't add new WARN() calls please, just properly clean up and handle > > > the error." [0] > > > > > > Also, switching to WARN_ON would then continue the atomic_check function > > > where it currently does exit with a real error code? > > > > So while I can live with WARN_ON as something that should never ever > > happen > > Right, I'm following the clarifications from jgg and Kees in that > thread, namely that WARN_ON is being used for 'how on earth did this > happen, the code is somehow completely broken' situations that > userspace should never be able to trigger under any circumstances. > > > I still think atomic_check should follow its function and report > > the error upwards like: > > > > if (WARN_ON(format < 0)) > > return format; > > Happy to do this if you prefer.
I do :-) . In the same line as the rest of your series does get rid of strange clutches that try to work around impossible situations, if the format thing is wrong, we should not continue, but fail the check function, as we did before. Heiko
