From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com,
Neal Gompa <ngompa13@gmail.com>
Subject: Re: [PATCH 1/3] btrfs: init devices always
Date: Wed, 17 Mar 2021 12:03:39 +0100 [thread overview]
Message-ID: <20210317110339.GP7604@twin.jikos.cz> (raw)
In-Reply-To: <dc687f1a-4b5c-ea69-2f36-96191f2d1ef3@oracle.com>
On Fri, Mar 12, 2021 at 01:57:32PM +0800, Anand Jain wrote:
>
>
> On 12/3/21 1:52 pm, Anand Jain wrote:
> > On 12/3/21 12:23 am, Josef Bacik wrote:
> >> Neal reported a panic trying to use -o rescue=all
> >>
> >> BUG: kernel NULL pointer dereference, address: 0000000000000030
> >> PGD 0 P4D 0
> >> Oops: 0000 [#1] SMP NOPTI
> >> CPU: 0 PID: 696 Comm: mount Tainted: G W 5.12.0-rc2+ #296
> >> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32
> >> 04/01/2014
> >> RIP: 0010:btrfs_device_init_dev_stats+0x1d/0x200
> >> RSP: 0018:ffffafaec1483bb8 EFLAGS: 00010286
> >> RAX: 0000000000000000 RBX: ffff9a5715bcb298 RCX: 0000000000000070
> >> RDX: ffff9a5703248000 RSI: ffff9a57052ea150 RDI: ffff9a5715bca400
> >> RBP: ffff9a57052ea150 R08: 0000000000000070 R09: ffff9a57052ea150
> >> R10: 000130faf0741c10 R11: 0000000000000000 R12: ffff9a5703700000
> >> R13: 0000000000000000 R14: ffff9a5715bcb278 R15: ffff9a57052ea150
> >> FS: 00007f600d122c40(0000) GS:ffff9a577bc00000(0000)
> >> knlGS:0000000000000000
> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 0000000000000030 CR3: 0000000112a46005 CR4: 0000000000370ef0
> >> Call Trace:
> >> ? btrfs_init_dev_stats+0x1f/0xf0
> >> ? kmem_cache_alloc+0xef/0x1f0
> >> btrfs_init_dev_stats+0x5f/0xf0
> >> open_ctree+0x10cb/0x1720
> >> btrfs_mount_root.cold+0x12/0xea
> >> legacy_get_tree+0x27/0x40
> >> vfs_get_tree+0x25/0xb0
> >> vfs_kern_mount.part.0+0x71/0xb0
> >> btrfs_mount+0x10d/0x380
> >> legacy_get_tree+0x27/0x40
> >> vfs_get_tree+0x25/0xb0
> >> path_mount+0x433/0xa00
> >> __x64_sys_mount+0xe3/0x120
> >> do_syscall_64+0x33/0x40
> >> entry_SYSCALL_64_after_hwframe+0x44/0xae
> >>
> >> This happens because when we call btrfs_init_dev_stats we do
> >> device->fs_info->dev_root. However device->fs_info isn't init'ed
> >> because we were only calling btrfs_init_devices_late() if we properly
> >> read the device root.
> >
> >
> >> However we don't actually need the device root to
> >> init the devices, this function simply assigns the devices their
> >> ->fs_info pointer properly, so this needs to be done unconditionally
> >> always so that we can properly deref device->fs_info in rescue cases.
>
>
> > btrfs_device_init_dev_stats() calls btrfs_search_slot() leading
> > to btrfs_search_slot_get_root(), and does de-reference root (dev_root)
> > to get fs_info.
>
> Never mind. patch 2/3 handles it. Spoke too early.
> Maybe can reorder the patches during integration.
I think swapping the order makes sense, though all the patches fix some
sort of crash, the number should be decreasing.
next prev parent reply other threads:[~2021-03-17 11:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 16:23 [PATCH 0/3] Handle bad dev_root properly with rescue=all Josef Bacik
2021-03-11 16:23 ` [PATCH 1/3] btrfs: init devices always Josef Bacik
2021-03-12 5:52 ` Anand Jain
2021-03-12 5:57 ` Anand Jain
2021-03-17 11:03 ` David Sterba [this message]
2021-03-12 5:58 ` Anand Jain
2021-03-11 16:23 ` [PATCH 2/3] btrfs: do not init dev stats if we have no dev_root Josef Bacik
2021-03-12 5:59 ` Anand Jain
2021-03-11 16:23 ` [PATCH 3/3] btrfs: don't init dev replace for bad dev root Josef Bacik
2021-03-12 6:50 ` Anand Jain
2021-03-11 19:18 ` [PATCH 0/3] Handle bad dev_root properly with rescue=all Neal Gompa
2021-03-17 12:27 ` David Sterba
2021-03-17 15:30 ` Josef Bacik
2021-03-18 15:43 ` David Sterba
2021-03-18 20:45 ` Josef Bacik
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=20210317110339.GP7604@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=ngompa13@gmail.com \
/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