[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Warning about WARN_ON()

Warning about WARN_ON()

Posted Apr 18, 2024 20:33 UTC (Thu) by roc (subscriber, #30627)
In reply to: Warning about WARN_ON() by ukleinek
Parent article: Warning about WARN_ON()

This is a fantastic idea, bravo!


to post comments

Warning about WARN_ON()

Posted Apr 18, 2024 22:34 UTC (Thu) by snajpa (subscriber, #73467) [Link] (1 responses)

*if* the WARN_ONs contained a kernel version, year, year+month (or ...?), one could teach the panic_on_warn to recognize a cut off, that would be used to limit the warns that trigger a panic to already-known subset (so the kernel can be upgraded, panic_on_warn stays at the same value for most of the fleet while keeping an eye on just a subset where it gets bumped)...

but that's a big if :-D it would probably be ugly to annotate all WARN_ONs with a tag for when they appeared - and not all kernels get built from a git clone... perhaps there could be an indirect file where that information could live, auto-generated from git?

not that I care personally to implement it, I am happy with the current panic_on_warn as is, without complaints

Warning about WARN_ON()

Posted Apr 19, 2024 17:32 UTC (Fri) by Heretic_Blacksheep (subscriber, #169992) [Link]

Theoretically it should just be given a comment like "//added <date> for <specific check case that shouldn't happen> NOTE: if you panic on this, that's YOUR choice". Just because people abuse a sysctl tweak doesn't mean the rest of its users should lose a useful tool, which is kinda what that documentation change suggests.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds