I'm providing this patch as an example of how to expand the BUG_ON/WARN_ON macros to provide more information or extra capabilities.
Josef Bacik has been working on working with a user on IRC to recover data from a btrfs volume, and the 'work-in-progress' solution involved expanding the BUG_ON/WARN_ON macros in a different method that would lose the information on where the BUG_ON/WARN_ON occured. When the macro is structured like this patch, it will still provide the location of the BUG_ON/WARN_ON in the code. This patch also highlights that BUG_ON and WARN_ON are the same thing in btrfs-progs. All WARN_ONs are treated the same as BUG_ONs, and the program is halted. Should we convert all our btrfs-progs WARN_ONs to BUG_ONs to allow us to implement a true WARN_ON functionality? Signed-off-by: Mitch Harder <mitch.har...@sabayonlinux.org> --- kerncompat.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/kerncompat.h b/kerncompat.h index f370cd8..79661f5 100644 --- a/kerncompat.h +++ b/kerncompat.h @@ -233,9 +233,19 @@ static inline long IS_ERR(const void *ptr) #define kstrdup(x, y) strdup(x) #define kfree(x) free(x) -#define BUG_ON(c) assert(!(c)) -#define WARN_ON(c) assert(!(c)) +#define BUG_ON(c) do { \ + if (c) { \ + fprintf(stderr, "BUG_ON!\n"); \ + assert(!(c)); \ + } \ +} while (0) +#define WARN_ON(c) do { \ + if (c) { \ + fprintf(stderr, "WARN_ON!\n"); \ + assert(!(c)); \ + } \ +} while (0) #define container_of(ptr, type, member) ({ \ const typeof( ((type *)0)->member ) *__mptr = (ptr); \ -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html