From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Bug 5.7-rc: lockdep warning, chunk_mutex/device_list_mutex
Date: Wed, 13 May 2020 03:25:42 +0800 [thread overview]
Message-ID: <65c57205-2c42-1e14-f3ea-55e2f7f0b097@oracle.com> (raw)
In-Reply-To: <20200512232827.GI18421@twin.jikos.cz>
On 13/5/2020 7:28 am, David Sterba wrote:
> On Tue, May 12, 2020 at 04:15:46PM +0200, David Sterba wrote:
>> [ 5174.283784] -> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
>> [ 5174.286134] __lock_acquire+0x581/0xae0
>> [ 5174.287563] lock_acquire+0xa3/0x400
>> [ 5174.289033] __mutex_lock+0xa0/0xaf0
>> [ 5174.290488] btrfs_init_new_device+0x316/0x12f0 [btrfs]
>> [ 5174.292209] btrfs_ioctl+0xc3c/0x2590 [btrfs]
>
> ioctl called
>
>> [ 5174.293673] ksys_ioctl+0x68/0xa0
>> [ 5174.294883] __x64_sys_ioctl+0x16/0x20
>> [ 5174.296231] do_syscall_64+0x50/0x210
>> [ 5174.297548] entry_SYSCALL_64_after_hwframe+0x49/0xb3
>> [ 5174.299278]
>> [ 5174.299278] -> #0 (&fs_devs->device_list_mutex){+.+.}-{3:3}:
>> [ 5174.301760] check_prev_add+0x98/0xa20
>> [ 5174.303219] validate_chain+0xa6c/0x29e0
>> [ 5174.304770] __lock_acquire+0x581/0xae0
>> [ 5174.306274] lock_acquire+0xa3/0x400
>> [ 5174.307716] __mutex_lock+0xa0/0xaf0
>> [ 5174.309145] clone_fs_devices+0x3f/0x170 [btrfs]
>> [ 5174.310757] read_one_dev+0xc4/0x500 [btrfs]
>> [ 5174.312293] btrfs_read_chunk_tree+0x202/0x2a0 [btrfs]
>> [ 5174.313946] open_ctree+0x7a3/0x10db [btrfs]
>
> ... while the filesystem is being set up. This is actually possible
> because this is with enabled seeding, so the mounted filesystem accesses
> the seeding filesystem's structures when cloning the devices.
>
> Should be fixed by lifting the device_list_mutex from clone_fs_devices
> to some of it's callers. In btrfs_read_chunk_tree it's between the uuid
> mutex and chunk mutex, in btrfs_init_new_device lock device_list_mutex
> before "if (seeding_dev)".
>
Two strange things as of now, why we see this only now and mount thread
is still running but we have the device add ioctl thread.
>> [ 5174.315411] btrfs_mount_root.cold+0xe/0xcc [btrfs]
>> [ 5174.317122] legacy_get_tree+0x2d/0x60
>> [ 5174.318543] vfs_get_tree+0x1d/0xb0
>> [ 5174.319844] fc_mount+0xe/0x40
>> [ 5174.321122] vfs_kern_mount.part.0+0x71/0x90
>> [ 5174.322688] btrfs_mount+0x147/0x3e0 [btrfs]
>> [ 5174.324250] legacy_get_tree+0x2d/0x60
>> [ 5174.325644] vfs_get_tree+0x1d/0xb0
>> [ 5174.326978] do_mount+0x7d5/0xa40
>> [ 5174.328294] __x64_sys_mount+0x8e/0xd0
>> [ 5174.329829] do_syscall_64+0x50/0x210
>> [ 5174.331260] entry_SYSCALL_64_after_hwframe+0x49/0xb3
next prev parent reply other threads:[~2020-05-13 3:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 14:12 Pending bugs for 5.7 David Sterba
2020-05-12 14:14 ` Bug 5.7-rc: root leak, eb leak David Sterba
2020-05-12 23:03 ` David Sterba
2020-05-13 11:54 ` Johannes Thumshirn
2020-05-13 11:57 ` Qu Wenruo
2020-05-13 12:06 ` Johannes Thumshirn
2020-05-13 12:11 ` Qu Wenruo
2020-05-13 12:17 ` Johannes Thumshirn
2020-05-13 12:29 ` Johannes Thumshirn
2020-05-12 14:15 ` Bug 5.7-rc: write-time leaf corruption detected David Sterba
2020-05-12 14:26 ` Filipe Manana
2020-05-13 3:10 ` Qu Wenruo
2020-05-13 3:17 ` Qu Wenruo
2020-05-13 9:25 ` Filipe Manana
2020-05-19 14:26 ` Bug 5.7-rc: write-time leaf corruption detected (fixed) David Sterba
2020-05-12 14:15 ` Bug 5.7-rc: lockdep warning, chunk_mutex/device_list_mutex David Sterba
2020-05-12 23:28 ` David Sterba
2020-05-12 19:25 ` Anand Jain [this message]
2020-05-13 19:46 ` [PATCH] btrfs: fix lockdep warning chunk_mutex vs device_list_mutex Anand Jain
2020-05-15 17:40 ` David Sterba
2020-05-16 3:43 ` Anand Jain
2020-05-18 11:07 ` Anand Jain
2020-05-18 15:28 ` David Sterba
2020-05-12 14:15 ` Bug 5.7-rc: lockdep warning, fs_reclaim David Sterba
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=65c57205-2c42-1e14-f3ea-55e2f7f0b097@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--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;
as well as URLs for NNTP newsgroup(s).