From: David Sterba <dsterba@suse.cz>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/3] btrfs: fix lockdep splat in open_fs_devices
Date: Wed, 22 Jul 2020 14:57:46 +0200 [thread overview]
Message-ID: <20200722125745.GS3703@twin.jikos.cz> (raw)
In-Reply-To: <20200717191229.2283043-2-josef@toxicpanda.com>
On Fri, Jul 17, 2020 at 03:12:27PM -0400, Josef Bacik wrote:
> Fix this by not holding the ->device_list_mutex at this point. The
> device_list_mutex exists to protect us from modifying the device list
> while the file system is running.
>
> However it can also be modified by doing a scan on a device. But this
> action is specifically protected by the uuid_mutex, which we are holding
> here. We cannot race with opening at this point because we have the
> ->s_mount lock held during the mount. Not having the
> ->device_list_mutex here is perfectly safe as we're not going to change
> the devices at this point.
Agreed, the uuid_mutex is sufficient here, since 81ffd56b574 ("btrfs:
fix mount and ioctl device scan ioctl race") that excludes the critical
parts of mount and scan.
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> fs/btrfs/volumes.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index ce01e44f8134..20295441251a 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -258,6 +258,9 @@ static int __btrfs_map_block(struct btrfs_fs_info *fs_info,
> * may be used to exclude some operations from running concurrently without any
> * modifications to the list (see write_all_supers)
> *
> + * Is not required at mount and close times, because our device list is
> + * protected by the uuid_mutex at that point.
This is correct, however there's one comment a few lines above about
unid_mutex
"does not protect: manipulation of the fs_devices::devices list!"
so I'll update it means 'not in general but there are exceptions like
mount context'.
> + *
> * balance_mutex
> * -------------
> * protects balance structures (status, state) and context accessed from
> @@ -602,6 +605,11 @@ static int btrfs_free_stale_devices(const char *path,
> return ret;
> }
>
> +/*
> + * This is only used on mount, and we are protected from competing things
> + * messing with our fs_devices by the uuid_mutex, thus we do not need the
> + * fs_devices->device_list_mutex here.
> + */
> static int btrfs_open_one_device(struct btrfs_fs_devices *fs_devices,
> struct btrfs_device *device, fmode_t flags,
> void *holder)
> @@ -1230,7 +1238,6 @@ int btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
>
> lockdep_assert_held(&uuid_mutex);
>
> - mutex_lock(&fs_devices->device_list_mutex);
I'll leave a comment here as the device list is clearly modified
(list_sort).
> if (fs_devices->opened) {
> fs_devices->opened++;
> ret = 0;
> @@ -1238,7 +1245,6 @@ int btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
> list_sort(NULL, &fs_devices->devices, devid_cmp);
> ret = open_fs_devices(fs_devices, flags, holder);
> }
> - mutex_unlock(&fs_devices->device_list_mutex);
>
> return ret;
> }
> --
> 2.24.1
next prev parent reply other threads:[~2020-07-22 12:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 19:12 [PATCH 0/3] Fix a few lockdep splats Josef Bacik
2020-07-17 19:12 ` [PATCH 1/3] btrfs: fix lockdep splat in open_fs_devices Josef Bacik
2020-07-22 12:57 ` David Sterba [this message]
2020-07-17 19:12 ` [PATCH 2/3] btrfs: move the chunk_mutex in btrfs_read_chunk_tree Josef Bacik
2020-07-20 7:23 ` Anand Jain
2020-07-22 13:36 ` David Sterba
2020-07-22 13:47 ` David Sterba
2020-07-17 19:12 ` [PATCH 3/3] btrfs: fix lockdep splat from btrfs_dump_space_info Josef Bacik
2020-07-21 10:00 ` [PATCH 0/3] Fix a few lockdep splats David Sterba
2020-07-22 14:02 ` 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=20200722125745.GS3703@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.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