Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] btrfs: print assertion failure report and stack trace from the same line
Date: Fri, 26 May 2023 16:57:05 +0200	[thread overview]
Message-ID: <20230526145705.GC575@twin.jikos.cz> (raw)
In-Reply-To: <20230503190816.8800-1-dsterba@suse.com>

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.

      parent reply	other threads:[~2023-05-26 15:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230526145705.GC575@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox