* [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line
@ 2023-05-03 19:08 David Sterba
2023-05-04 1:19 ` Wang Yugui
2023-05-26 14:57 ` David Sterba
0 siblings, 2 replies; 4+ messages in thread
From: David Sterba @ 2023-05-03 19:08 UTC (permalink / raw)
To: linux-btrfs; +Cc: David Sterba
Assertions reports are split into two parts, the exact file and location
of the condition and then the stack trace printed from
btrfs_assertfail(). This means all the stack traces report the same line
and this is what's typically reported by various tools, making it harder
to distinguish the reports.
[403.2467] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4259
[403.2479] ------------[ cut here ]------------
[403.2484] kernel BUG at fs/btrfs/messages.c:259!
[403.2488] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[403.2493] CPU: 2 PID: 23202 Comm: umount Not tainted 6.2.0-rc4-default+ #67
[403.2499] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
[403.2509] RIP: 0010:btrfs_assertfail+0x19/0x1b [btrfs]
...
[403.2595] Call Trace:
[403.2598] <TASK>
[403.2601] btrfs_free_block_groups.cold+0x52/0xae [btrfs]
[403.2608] close_ctree+0x6c2/0x761 [btrfs]
[403.2613] ? __wait_for_common+0x2b8/0x360
[403.2618] ? btrfs_cleanup_one_transaction.cold+0x7a/0x7a [btrfs]
[403.2626] ? mark_held_locks+0x6b/0x90
[403.2630] ? lockdep_hardirqs_on_prepare+0x13d/0x200
[403.2636] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
[403.2642] ? trace_hardirqs_on+0x2d/0x110
[403.2646] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
[403.2652] generic_shutdown_super+0xb0/0x1c0
[403.2657] kill_anon_super+0x1e/0x40
[403.2662] btrfs_kill_super+0x25/0x30 [btrfs]
[403.2668] deactivate_locked_super+0x4c/0xc0
By making btrfs_assertfail a macro we'll get the same line number for
the BUG output:
[63.5736] assertion failed: 0, in fs/btrfs/super.c:1572
[63.5758] ------------[ cut here ]------------
[63.5782] kernel BUG at fs/btrfs/super.c:1572!
[63.5807] invalid opcode: 0000 [#2] PREEMPT SMP KASAN
[63.5831] CPU: 0 PID: 859 Comm: mount Tainted: G D 6.3.0-rc7-default+ #2062
[63.5868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
[63.5905] RIP: 0010:btrfs_mount+0x24/0x30 [btrfs]
[63.5964] RSP: 0018:ffff88800e69fcd8 EFLAGS: 00010246
[63.5982] RAX: 000000000000002d RBX: ffff888008fc1400 RCX: 0000000000000000
[63.6004] RDX: 0000000000000000 RSI: ffffffffb90fd868 RDI: ffffffffbcc3ff20
[63.6026] RBP: ffffffffc081b200 R08: 0000000000000001 R09: ffff88800e69fa27
[63.6046] R10: ffffed1001cd3f44 R11: 0000000000000001 R12: ffff888005a3c370
[63.6062] R13: ffffffffc058e830 R14: 0000000000000000 R15: 00000000ffffffff
[63.6081] FS: 00007f7b3561f800(0000) GS:ffff88806c600000(0000) knlGS:0000000000000000
[63.6105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[63.6120] CR2: 00007fff83726e10 CR3: 0000000002a9e000 CR4: 00000000000006b0
[63.6137] Call Trace:
[63.6143] <TASK>
[63.6148] legacy_get_tree+0x80/0xd0
[63.6158] vfs_get_tree+0x43/0x120
[63.6166] do_new_mount+0x1f3/0x3d0
[63.6176] ? do_add_mount+0x140/0x140
[63.6187] ? cap_capable+0xa4/0xe0
[63.6197] path_mount+0x223/0xc10
This comes at a cost of bloating the final btrfs.ko module due all the
inlining, as long as assertions are compiled in. This is a must for
debugging builds but this is often enabled on release builds too.
Release build:
text data bss dec hex filename
1251676 20317 16088 1288081 13a791 pre/btrfs.ko
1260612 29473 16088 1306173 13ee3d post/btrfs.ko
DELTA: +8936
Signed-off-by: David Sterba <dsterba@suse.com>
---
fs/btrfs/messages.c | 8 --------
fs/btrfs/messages.h | 8 +++++++-
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/messages.c b/fs/btrfs/messages.c
index 310a05cf95ef..23fc11af498a 100644
--- a/fs/btrfs/messages.c
+++ b/fs/btrfs/messages.c
@@ -252,14 +252,6 @@ void __cold _btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt,
}
#endif
-#ifdef CONFIG_BTRFS_ASSERT
-void __cold __noreturn btrfs_assertfail(const char *expr, const char *file, int line)
-{
- pr_err("assertion failed: %s, in %s:%d\n", expr, file, line);
- BUG();
-}
-#endif
-
void __cold btrfs_print_v0_err(struct btrfs_fs_info *fs_info)
{
btrfs_err(fs_info,
diff --git a/fs/btrfs/messages.h b/fs/btrfs/messages.h
index ac2d1982ba3d..0797df12c1ae 100644
--- a/fs/btrfs/messages.h
+++ b/fs/btrfs/messages.h
@@ -4,6 +4,8 @@
#define BTRFS_MESSAGES_H
#include <linux/types.h>
+#include <linux/printk.h>
+#include <linux/bug.h>
struct btrfs_fs_info;
@@ -160,7 +162,11 @@ do { \
} while (0)
#ifdef CONFIG_BTRFS_ASSERT
-void __cold __noreturn btrfs_assertfail(const char *expr, const char *file, int line);
+
+#define btrfs_assertfail(expr, file, line) ({ \
+ pr_err("assertion failed: %s, in %s:%d\n", (expr), (file), (line)); \
+ BUG(); \
+})
#define ASSERT(expr) \
(likely(expr) ? (void)0 : btrfs_assertfail(#expr, __FILE__, __LINE__))
--
2.40.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line
2023-05-03 19:08 [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line David Sterba
@ 2023-05-04 1:19 ` Wang Yugui
2023-05-04 11:09 ` David Sterba
2023-05-26 14:57 ` David Sterba
1 sibling, 1 reply; 4+ messages in thread
From: Wang Yugui @ 2023-05-04 1:19 UTC (permalink / raw)
To: David Sterba; +Cc: linux-btrfs
Hi,
> Assertions reports are split into two parts, the exact file and location
> of the condition and then the stack trace printed from
> btrfs_assertfail(). This means all the stack traces report the same line
> and this is what's typically reported by various tools, making it harder
> to distinguish the reports.
>
> [403.2467] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4259
> [403.2479] ------------[ cut here ]------------
> [403.2484] kernel BUG at fs/btrfs/messages.c:259!
> [403.2488] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> [403.2493] CPU: 2 PID: 23202 Comm: umount Not tainted 6.2.0-rc4-default+ #67
> [403.2499] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
> [403.2509] RIP: 0010:btrfs_assertfail+0x19/0x1b [btrfs]
> ...
> [403.2595] Call Trace:
> [403.2598] <TASK>
> [403.2601] btrfs_free_block_groups.cold+0x52/0xae [btrfs]
> [403.2608] close_ctree+0x6c2/0x761 [btrfs]
> [403.2613] ? __wait_for_common+0x2b8/0x360
> [403.2618] ? btrfs_cleanup_one_transaction.cold+0x7a/0x7a [btrfs]
> [403.2626] ? mark_held_locks+0x6b/0x90
> [403.2630] ? lockdep_hardirqs_on_prepare+0x13d/0x200
> [403.2636] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
> [403.2642] ? trace_hardirqs_on+0x2d/0x110
> [403.2646] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
> [403.2652] generic_shutdown_super+0xb0/0x1c0
> [403.2657] kill_anon_super+0x1e/0x40
> [403.2662] btrfs_kill_super+0x25/0x30 [btrfs]
> [403.2668] deactivate_locked_super+0x4c/0xc0
>
> By making btrfs_assertfail a macro we'll get the same line number for
> the BUG output:
>
> [63.5736] assertion failed: 0, in fs/btrfs/super.c:1572
> [63.5758] ------------[ cut here ]------------
> [63.5782] kernel BUG at fs/btrfs/super.c:1572!
> [63.5807] invalid opcode: 0000 [#2] PREEMPT SMP KASAN
> [63.5831] CPU: 0 PID: 859 Comm: mount Tainted: G D 6.3.0-rc7-default+ #2062
> [63.5868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> [63.5905] RIP: 0010:btrfs_mount+0x24/0x30 [btrfs]
> [63.5964] RSP: 0018:ffff88800e69fcd8 EFLAGS: 00010246
> [63.5982] RAX: 000000000000002d RBX: ffff888008fc1400 RCX: 0000000000000000
> [63.6004] RDX: 0000000000000000 RSI: ffffffffb90fd868 RDI: ffffffffbcc3ff20
> [63.6026] RBP: ffffffffc081b200 R08: 0000000000000001 R09: ffff88800e69fa27
> [63.6046] R10: ffffed1001cd3f44 R11: 0000000000000001 R12: ffff888005a3c370
> [63.6062] R13: ffffffffc058e830 R14: 0000000000000000 R15: 00000000ffffffff
> [63.6081] FS: 00007f7b3561f800(0000) GS:ffff88806c600000(0000) knlGS:0000000000000000
> [63.6105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [63.6120] CR2: 00007fff83726e10 CR3: 0000000002a9e000 CR4: 00000000000006b0
> [63.6137] Call Trace:
> [63.6143] <TASK>
> [63.6148] legacy_get_tree+0x80/0xd0
> [63.6158] vfs_get_tree+0x43/0x120
> [63.6166] do_new_mount+0x1f3/0x3d0
> [63.6176] ? do_add_mount+0x140/0x140
> [63.6187] ? cap_capable+0xa4/0xe0
> [63.6197] path_mount+0x223/0xc10
>
> This comes at a cost of bloating the final btrfs.ko module due all the
> inlining, as long as assertions are compiled in. This is a must for
> debugging builds but this is often enabled on release builds too.
>
> Release build:
>
> text data bss dec hex filename
> 1251676 20317 16088 1288081 13a791 pre/btrfs.ko
> 1260612 29473 16088 1306173 13ee3d post/btrfs.ko
>
> DELTA: +8936
>
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
> fs/btrfs/messages.c | 8 --------
> fs/btrfs/messages.h | 8 +++++++-
> 2 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/fs/btrfs/messages.c b/fs/btrfs/messages.c
> index 310a05cf95ef..23fc11af498a 100644
> --- a/fs/btrfs/messages.c
> +++ b/fs/btrfs/messages.c
> @@ -252,14 +252,6 @@ void __cold _btrfs_printk(const struct btrfs_fs_info *fs_info, const char *fmt,
> }
> #endif
>
> -#ifdef CONFIG_BTRFS_ASSERT
> -void __cold __noreturn btrfs_assertfail(const char *expr, const char *file, int line)
> -{
> - pr_err("assertion failed: %s, in %s:%d\n", expr, file, line);
> - BUG();
> -}
> -#endif
> -
> void __cold btrfs_print_v0_err(struct btrfs_fs_info *fs_info)
> {
> btrfs_err(fs_info,
> diff --git a/fs/btrfs/messages.h b/fs/btrfs/messages.h
> index ac2d1982ba3d..0797df12c1ae 100644
> --- a/fs/btrfs/messages.h
> +++ b/fs/btrfs/messages.h
> @@ -4,6 +4,8 @@
> #define BTRFS_MESSAGES_H
>
> #include <linux/types.h>
> +#include <linux/printk.h>
> +#include <linux/bug.h>
>
> struct btrfs_fs_info;
>
> @@ -160,7 +162,11 @@ do { \
> } while (0)
>
> #ifdef CONFIG_BTRFS_ASSERT
> -void __cold __noreturn btrfs_assertfail(const char *expr, const char *file, int line);
> +
> +#define btrfs_assertfail(expr, file, line) ({ \
> + pr_err("assertion failed: %s, in %s:%d\n", (expr), (file), (line)); \
> + BUG(); \
> +})
>
> #define ASSERT(expr) \
> (likely(expr) ? (void)0 : btrfs_assertfail(#expr, __FILE__, __LINE__))
> --
> 2.40.0
We need remove btrfs_assertfail in tools/objtool/check.c
that come from commit f372463124df ?
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2023/05/04
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line
2023-05-04 1:19 ` Wang Yugui
@ 2023-05-04 11:09 ` David Sterba
0 siblings, 0 replies; 4+ messages in thread
From: David Sterba @ 2023-05-04 11:09 UTC (permalink / raw)
To: Wang Yugui; +Cc: David Sterba, linux-btrfs
On Thu, May 04, 2023 at 09:19:33AM +0800, Wang Yugui wrote:
> > #ifdef CONFIG_BTRFS_ASSERT
> > -void __cold __noreturn btrfs_assertfail(const char *expr, const char *file, int line);
> > +
> > +#define btrfs_assertfail(expr, file, line) ({ \
> > + pr_err("assertion failed: %s, in %s:%d\n", (expr), (file), (line)); \
> > + BUG(); \
> > +})
> >
> > #define ASSERT(expr) \
> > (likely(expr) ? (void)0 : btrfs_assertfail(#expr, __FILE__, __LINE__))
> > --
> > 2.40.0
>
> We need remove btrfs_assertfail in tools/objtool/check.c
> that come from commit f372463124df ?
Yes if we agree to merge this patch in the end. As I'm reading the
objtool checks, it's not a hard bug if the function does not exist (but
is in the list of exceptions). Thanks for noticing it, I'll keep it
in mind.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line
2023-05-03 19:08 [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line David Sterba
2023-05-04 1:19 ` Wang Yugui
@ 2023-05-26 14:57 ` David Sterba
1 sibling, 0 replies; 4+ messages in thread
From: David Sterba @ 2023-05-26 14:57 UTC (permalink / raw)
To: David Sterba; +Cc: linux-btrfs
On Wed, May 03, 2023 at 09:08:16PM +0200, David Sterba wrote:
> Assertions reports are split into two parts, the exact file and location
> of the condition and then the stack trace printed from
> btrfs_assertfail(). This means all the stack traces report the same line
> and this is what's typically reported by various tools, making it harder
> to distinguish the reports.
>
> [403.2467] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4259
> [403.2479] ------------[ cut here ]------------
> [403.2484] kernel BUG at fs/btrfs/messages.c:259!
> [403.2488] invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> [403.2493] CPU: 2 PID: 23202 Comm: umount Not tainted 6.2.0-rc4-default+ #67
> [403.2499] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
> [403.2509] RIP: 0010:btrfs_assertfail+0x19/0x1b [btrfs]
> ...
> [403.2595] Call Trace:
> [403.2598] <TASK>
> [403.2601] btrfs_free_block_groups.cold+0x52/0xae [btrfs]
> [403.2608] close_ctree+0x6c2/0x761 [btrfs]
> [403.2613] ? __wait_for_common+0x2b8/0x360
> [403.2618] ? btrfs_cleanup_one_transaction.cold+0x7a/0x7a [btrfs]
> [403.2626] ? mark_held_locks+0x6b/0x90
> [403.2630] ? lockdep_hardirqs_on_prepare+0x13d/0x200
> [403.2636] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
> [403.2642] ? trace_hardirqs_on+0x2d/0x110
> [403.2646] ? __call_rcu_common.constprop.0+0x1ea/0x3d0
> [403.2652] generic_shutdown_super+0xb0/0x1c0
> [403.2657] kill_anon_super+0x1e/0x40
> [403.2662] btrfs_kill_super+0x25/0x30 [btrfs]
> [403.2668] deactivate_locked_super+0x4c/0xc0
>
> By making btrfs_assertfail a macro we'll get the same line number for
> the BUG output:
>
> [63.5736] assertion failed: 0, in fs/btrfs/super.c:1572
> [63.5758] ------------[ cut here ]------------
> [63.5782] kernel BUG at fs/btrfs/super.c:1572!
> [63.5807] invalid opcode: 0000 [#2] PREEMPT SMP KASAN
> [63.5831] CPU: 0 PID: 859 Comm: mount Tainted: G D 6.3.0-rc7-default+ #2062
> [63.5868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> [63.5905] RIP: 0010:btrfs_mount+0x24/0x30 [btrfs]
> [63.5964] RSP: 0018:ffff88800e69fcd8 EFLAGS: 00010246
> [63.5982] RAX: 000000000000002d RBX: ffff888008fc1400 RCX: 0000000000000000
> [63.6004] RDX: 0000000000000000 RSI: ffffffffb90fd868 RDI: ffffffffbcc3ff20
> [63.6026] RBP: ffffffffc081b200 R08: 0000000000000001 R09: ffff88800e69fa27
> [63.6046] R10: ffffed1001cd3f44 R11: 0000000000000001 R12: ffff888005a3c370
> [63.6062] R13: ffffffffc058e830 R14: 0000000000000000 R15: 00000000ffffffff
> [63.6081] FS: 00007f7b3561f800(0000) GS:ffff88806c600000(0000) knlGS:0000000000000000
> [63.6105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [63.6120] CR2: 00007fff83726e10 CR3: 0000000002a9e000 CR4: 00000000000006b0
> [63.6137] Call Trace:
> [63.6143] <TASK>
> [63.6148] legacy_get_tree+0x80/0xd0
> [63.6158] vfs_get_tree+0x43/0x120
> [63.6166] do_new_mount+0x1f3/0x3d0
> [63.6176] ? do_add_mount+0x140/0x140
> [63.6187] ? cap_capable+0xa4/0xe0
> [63.6197] path_mount+0x223/0xc10
>
> This comes at a cost of bloating the final btrfs.ko module due all the
> inlining, as long as assertions are compiled in. This is a must for
> debugging builds but this is often enabled on release builds too.
>
> Release build:
>
> text data bss dec hex filename
> 1251676 20317 16088 1288081 13a791 pre/btrfs.ko
> 1260612 29473 16088 1306173 13ee3d post/btrfs.ko
>
> DELTA: +8936
>
> Signed-off-by: David Sterba <dsterba@suse.com>
I'm adding this to misc-next. Recent patchsets reduced size of .ko so
the bloat isn't too bad.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-05-26 15:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-03 19:08 [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line David Sterba
2023-05-04 1:19 ` Wang Yugui
2023-05-04 11:09 ` David Sterba
2023-05-26 14:57 ` David Sterba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox