From: Andrew Price <anprice@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: miklos@szeredi.hu, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] vfs: Create fs_context-aware mount_bdev() replacement
Date: Tue, 26 Mar 2019 21:02:25 +0000 [thread overview]
Message-ID: <ad854f75-6b42-7d8a-2cc6-cbcf528c8458@redhat.com> (raw)
In-Reply-To: <155301261082.7556.2558480789011010142.stgit@warthog.procyon.org.uk>
Hi David,
I've been testing gfs2 on top of this patch and it seems...
On 19/03/2019 16:23, David Howells wrote:
> Create a function, vfs_get_block_super(), that is fs_context-aware and a
> replacement for mount_bdev(). It caches the block device pointer and file
> open mode in the fs_context struct so that this information can be passed
> into sget_fc()'s test and set functions.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> fs/fs_context.c | 2 +
> fs/super.c | 106 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/fs_context.h | 6 ++
> 3 files changed, 114 insertions(+)
>
> diff --git a/fs/fs_context.c b/fs/fs_context.c
> index 87e3546b9a52..ea027762c0b2 100644
> --- a/fs/fs_context.c
> +++ b/fs/fs_context.c
> @@ -425,6 +425,8 @@ void put_fs_context(struct fs_context *fc)
>
> if (fc->need_free && fc->ops && fc->ops->free)
> fc->ops->free(fc);
> + if (fc->bdev)
> + blkdev_put(fc->bdev, fc->bdev_mode);
doing this means...
>
> security_free_mnt_opts(&fc->security);
> put_net(fc->net_ns);
> diff --git a/fs/super.c b/fs/super.c
> index f27ee08fb26f..85851adb0f19 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -1211,6 +1211,112 @@ int vfs_get_super(struct fs_context *fc,
> EXPORT_SYMBOL(vfs_get_super);
>
> #ifdef CONFIG_BLOCK
> +static int set_bdev_super_fc(struct super_block *s, struct fs_context *fc)
> +{
> + s->s_bdev = fc->bdev;
> + s->s_dev = s->s_bdev->bd_dev;
> + s->s_bdi = bdi_get(s->s_bdev->bd_bdi);
> + fc->bdev = NULL;
> + return 0;
> +}
> +
> +static int test_bdev_super_fc(struct super_block *s, struct fs_context *fc)
> +{
> + return s->s_bdev == fc->bdev;
> +}
> +
> +/**
> + * vfs_get_block_super - Get a superblock based on a single block device
> + * @fc: The filesystem context holding the parameters
> + * @keying: How to distinguish superblocks
> + * @fill_super: Helper to initialise a new superblock
> + */
> +int vfs_get_block_super(struct fs_context *fc,
> + int (*fill_super)(struct super_block *,
> + struct fs_context *))
> +{
> + struct block_device *bdev;
> + struct super_block *s;
> + int error = 0;
> +
> + fc->bdev_mode = FMODE_READ | FMODE_EXCL;
> + if (!(fc->sb_flags & SB_RDONLY))
> + fc->bdev_mode |= FMODE_WRITE;
> +
> + if (!fc->source)
> + return invalf(fc, "No source specified");
> +
> + bdev = blkdev_get_by_path(fc->source, fc->bdev_mode, fc->fs_type);
> + if (IS_ERR(bdev)) {
> + errorf(fc, "%s: Can't open blockdev", fc->source);
> + return PTR_ERR(bdev);
> + }
> +
> + /* Once the superblock is inserted into the list by sget_fc(), s_umount
> + * will protect the lockfs code from trying to start a snapshot while
> + * we are mounting
> + */
> + mutex_lock(&bdev->bd_fsfreeze_mutex);
> + if (bdev->bd_fsfreeze_count > 0) {
> + mutex_unlock(&bdev->bd_fsfreeze_mutex);
> + warnf(fc, "%pg: Can't mount, blockdev is frozen", bdev);
> + error = -EBUSY;
> + goto error_bdev;
> + }
> +
> + fc->bdev = bdev;
> + fc->sb_flags |= SB_NOSEC;
> + s = sget_fc(fc, test_bdev_super_fc, set_bdev_super_fc);
> + mutex_unlock(&bdev->bd_fsfreeze_mutex);
> + if (IS_ERR(s)) {
> + error = PTR_ERR(s);
> + goto error_bdev;
> + }
> +
> + if (s->s_root) {
> + /* Don't summarily change the RO/RW state. */
> + if ((fc->sb_flags ^ s->s_flags) & SB_RDONLY) {
> + warnf(fc, "%pg: Can't mount, would change RO state", bdev);
> + error = -EBUSY;
> + goto error_sb;
> + }
> +
> + /* s_umount nests inside bd_mutex during __invalidate_device().
> + * blkdev_put() acquires bd_mutex and can't be called under
> + * s_umount. Drop s_umount temporarily. This is safe as we're
> + * holding an active reference.
> + */
> + up_write(&s->s_umount);
> + blkdev_put(bdev, fc->bdev_mode);
> + down_write(&s->s_umount);
fc->bdev should be NULLed here (or, on the way out of sget_fc() might be
more appropriate) otherwise we get a double-blkdev_put() leading to NULL
pointer derefs later. This happens when I mount a device twice and then
unmount them, or mount it 3 times.
> + } else {
> + s->s_mode = fc->bdev_mode;
> + snprintf(s->s_id, sizeof(s->s_id), "%pg", bdev);
> + sb_set_blocksize(s, block_size(bdev));
> + error = fill_super(s, fc);
> + if (error)
> + goto error_sb;
> +
> + s->s_flags |= SB_ACTIVE;
> + bdev->bd_super = s;
> + }
> +
> + BUG_ON(fc->root);
Maybe BUG_ON(fc->bdev); too?
Cheers,
Andy
next prev parent reply other threads:[~2019-03-26 21:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 16:23 [RFC PATCH 0/4] fuse: Convert to fs_context David Howells
2019-03-19 16:23 ` [RFC PATCH 1/4] vfs: Create fs_context-aware mount_bdev() replacement David Howells
2019-03-26 21:02 ` Andrew Price [this message]
2019-03-27 11:23 ` David Howells
2019-03-27 13:51 ` Andrew Price
2019-03-19 16:23 ` [RFC PATCH 2/4] vfs: Make fs_parse() handle fs_param_is_fd-type params better David Howells
2019-03-19 16:23 ` [RFC PATCH 3/4] fuse: Convert to mount API David Howells
2019-03-19 16:23 ` [RFC PATCH 4/4] fuse: Move the subtype parameter into fuse David Howells
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=ad854f75-6b42-7d8a-2cc6-cbcf528c8458@redhat.com \
--to=anprice@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/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).