The patch titled documentation: when to BUG(), and when to not BUG() has been removed from the -mm tree. Its filename was documentation-when-to-bug-and-when-to-not-bug.patch This patch was dropped because it was merged into mainline or a subsystem tree The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ ------------------------------------------------------ Subject: documentation: when to BUG(), and when to not BUG() From: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx> Provide some basic advice about when to use BUG()/BUG_ON(): never, unless there's really no better option. This matches my understanding of the standard policy ... which seems not to be written down so far, outside of LKML messages that I haven't bookmarked. Signed-off-by: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx> Cc: Hans Verkuil <hverkuil@xxxxxxxxx> Cc: Ingo Molnar <mingo@xxxxxxx> Cc: Arjan van de Ven <arjan@xxxxxxxxxxxxx> Cc: Randy Dunlap <randy.dunlap@xxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- include/asm-generic/bug.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff -puN include/asm-generic/bug.h~documentation-when-to-bug-and-when-to-not-bug include/asm-generic/bug.h --- a/include/asm-generic/bug.h~documentation-when-to-bug-and-when-to-not-bug +++ a/include/asm-generic/bug.h @@ -28,6 +28,17 @@ struct bug_entry { #define BUGFLAG_WARNING (1<<0) #endif /* CONFIG_GENERIC_BUG */ +/* + * Don't use BUG() or BUG_ON() unless there's really no way out; one + * example might be detecting data structure corruption in the middle + * of an operation that can't be backed out of. If the (sub)system + * can somehow continue operating, perhaps with reduced functionality, + * it's probably not BUG-worthy. + * + * If you're tempted to BUG(), think again: is completely giving up + * really the *only* solution? There are usually better options, where + * users don't need to reboot ASAP and can mostly shut down cleanly. + */ #ifndef HAVE_ARCH_BUG #define BUG() do { \ printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \ @@ -39,6 +50,12 @@ struct bug_entry { #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0) #endif +/* + * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report + * significant issues that need prompt attention if they should ever + * appear at runtime. Use the versions with printk format strings + * to provide better diagnostics. + */ #ifndef __WARN #ifndef __ASSEMBLY__ extern void warn_slowpath(const char *file, const int line, _ Patches currently in -mm which might be from dbrownell@xxxxxxxxxxxxxxxxxxxxx are origin.patch linux-next.patch acpi-fix-acpi_fadt_s4_rtc_wake-comment.patch usb-driver-for-freescale-quicc-engine-usb-host-controller.patch usb-fsl_qe_udc-fix-oops-on-qe-udc-probe-failure.patch usb-fsl_qe_udc-fix-recursive-locking-bug-in-ch9getstatus.patch usb-fsl_qe_udc-fix-disconnects-reporting-during-bus-reset.patch usb-fsl_qe_udc-fix-muram-corruption-by-disabled-endpoints.patch usb-fsl_qe_udc-fix-stalled-tx-requests-bug.patch rtc-ds1307-remove-legacy-probe-checks.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html