From: Vivek Goyal <vgoyal@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Linux fsdevel mailing list <linux-fsdevel@vger.kernel.org>,
linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, miklos@szeredi.hu, amir73il@gmail.com,
willy@infradead.org, jack@suse.cz, sargun@sargun.me
Subject: Re: [PATCH] vfs, syncfs: Do not ignore return code from ->sync_fs()
Date: Wed, 16 Dec 2020 12:16:18 -0500 [thread overview]
Message-ID: <20201216171618.GB3177@redhat.com> (raw)
In-Reply-To: <2b48fe655bd1f821cf575028bc6f811934dad847.camel@kernel.org>
On Wed, Dec 16, 2020 at 10:53:16AM -0500, Jeff Layton wrote:
> On Wed, 2020-12-16 at 10:44 -0500, Jeff Layton wrote:
> > On Wed, 2020-12-16 at 10:14 -0500, Vivek Goyal wrote:
> > > On Wed, Dec 16, 2020 at 09:57:49AM -0500, Jeff Layton wrote:
> > > > On Wed, 2020-12-16 at 09:38 -0500, Vivek Goyal wrote:
> > > > > I see that current implementation of __sync_filesystem() ignores the
> > > > > return code from ->sync_fs(). I am not sure why that's the case.
> > > > >
> > > > > Ignoring ->sync_fs() return code is problematic for overlayfs where
> > > > > it can return error if sync_filesystem() on upper super block failed.
> > > > > That error will simply be lost and sycnfs(overlay_fd), will get
> > > > > success (despite the fact it failed).
> > > > >
> > > > > I am assuming that we want to continue to call __sync_blockdev()
> > > > > despite the fact that there have been errors reported from
> > > > > ->sync_fs(). So I wrote this simple patch which captures the
> > > > > error from ->sync_fs() but continues to call __sync_blockdev()
> > > > > and returns error from sync_fs() if there is one.
> > > > >
> > > > > There might be some very good reasons to not capture ->sync_fs()
> > > > > return code, I don't know. Hence thought of proposing this patch.
> > > > > Atleast I will get to know the reason. I still need to figure
> > > > > a way out how to propagate overlay sync_fs() errors to user
> > > > > space.
> > > > >
> > > > > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > > > > ---
> > > > > fs/sync.c | 8 ++++++--
> > > > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > > > >
> > > > > Index: redhat-linux/fs/sync.c
> > > > > ===================================================================
> > > > > --- redhat-linux.orig/fs/sync.c 2020-12-16 09:15:49.831565653 -0500
> > > > > +++ redhat-linux/fs/sync.c 2020-12-16 09:23:42.499853207 -0500
> > > > > @@ -30,14 +30,18 @@
> > > > > */
> > > > > static int __sync_filesystem(struct super_block *sb, int wait)
> > > > > {
> > > > > + int ret, ret2;
> > > > > +
> > > > > if (wait)
> > > > > sync_inodes_sb(sb);
> > > > > else
> > > > > writeback_inodes_sb(sb, WB_REASON_SYNC);
> > > > >
> > > > >
> > > > > if (sb->s_op->sync_fs)
> > > > > - sb->s_op->sync_fs(sb, wait);
> > > > > - return __sync_blockdev(sb->s_bdev, wait);
> > > > > + ret = sb->s_op->sync_fs(sb, wait);
> > > > > + ret2 = __sync_blockdev(sb->s_bdev, wait);
> > > > > +
> > > > > + return ret ? ret : ret2;
> > > > > }
> > > > >
> > > > >
> > > > > /*
> > > > >
> > > >
> > > > I posted a patchset that took a similar approach a couple of years ago,
> > > > and we decided not to go with it [1].
> > > >
> > > > While it's not ideal to ignore the error here, I think this is likely to
> > > > break stuff.
> > >
> > > So one side affect I see is that syncfs() might start returning errors
> > > in some cases which were not reported at all. I am wondering will that
> > > count as breakage.
> > >
> > > > What may be better is to just make sync_fs void return, so
> > > > people don't think that returned errors there mean anything.
> > >
> > > May be.
> > >
> > > But then question remains that how do we return error to user space
> > > in syncfs(fd) for overlayfs. I will not be surprised if other
> > > filesystems want to return errors as well.
> > >
> > > Shall I create new helpers and call these in case of syncfs(). But
> > > that too will start returning new errors on syncfs(). So it does
> > > not solve that problem (if it is a problem).
> > >
> > > Or we can define a new super block op say ->sync_fs2() and call that
> > > first and in that case capture return code. That way it will not
> > > impact existing cases and overlayfs can possibly make use of
> > > ->sync_fs2() and return error. IOW, impact will be limited to
> > > only file systems which chose to implement ->sync_fs2().
> > >
> > > Thanks
> > > Vivek
> > >
> >
> > Sure, it's possible to add a sb->sync_fs2, but the problem is that
> > sync_fs is a superblock op, and is missing a lot of important context
> > about how it got called.
> >
> > syncfs(2) syscall takes a file descriptor argument. I'd add a new f_op-
> > > syncfs vector and turn most of the current guts of the syncfs syscall
> > into a generic_syncfs() that gets called when f_op->syncfs isn't
> > defined.
> >
> > Overlayfs could then add a ->syncfs op that would give it control over
> > what error gets returned. With that, you could basically leave the old
> > sb->sync_fs routine alone.
> >
> > I think that's probably the safest approach for allowing overlayfs to
> > propagate syncfs errors from the upper layer to the overlay.
> >
>
> To be clear, I mean something like this (draft, untested) patch. You'd
> also need to add a new ->syncfs op for overlayfs, and that could just do
> a check_and_advance against the upper layer sb's errseq_t after calling
> sync_filesystem.
Hi Jeff,
This sounds interesting. Should work for overlayfs. Will make overlayfs
changes.
So basically a new file operations ->syncfs() which says sync filesystem
containing this file. Error code will be captured and returned to
user space. Also filesystem is responsible to check for writeback
errors.
Thanks
Vivek
>
> -----------------------8<-------------------------
>
> [PATCH] vfs: add new f_op->syncfs vector
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/sync.c | 30 +++++++++++++++++++++---------
> include/linux/fs.h | 1 +
> 2 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/fs/sync.c b/fs/sync.c
> index 1373a610dc78..fc7f73762b9e 100644
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@ -155,27 +155,39 @@ void emergency_sync(void)
> }
> }
>
> +static int generic_syncfs(struct file *file)
> +{
> + int ret, ret2;
> + struct super_block *sb = file->f_path.dentry->d_sb;
> +
> + down_read(&sb->s_umount);
> + ret = sync_filesystem(sb);
> + up_read(&sb->s_umount);
> +
> + ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err);
> +
> + fdput(f);
> + return ret ? ret : ret2;
> +}
> +
> /*
> * sync a single super
> */
> SYSCALL_DEFINE1(syncfs, int, fd)
> {
> struct fd f = fdget(fd);
> - struct super_block *sb;
> - int ret, ret2;
> + int ret;
>
> if (!f.file)
> return -EBADF;
> - sb = f.file->f_path.dentry->d_sb;
>
> - down_read(&sb->s_umount);
> - ret = sync_filesystem(sb);
> - up_read(&sb->s_umount);
> -
> - ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err);
> + if (f.file->f_op->syncfs)
> + ret = f.file->f_op->syncfs(f.file);
> + else
> + ret = generic_syncfs(f.file);
>
> fdput(f);
> - return ret ? ret : ret2;
> + return ret;
> }
>
> /**
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8667d0cdc71e..6710469b7e33 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1859,6 +1859,7 @@ struct file_operations {
> struct file *file_out, loff_t pos_out,
> loff_t len, unsigned int remap_flags);
> int (*fadvise)(struct file *, loff_t, loff_t, int);
> + int (*syncfs)(struct file *);
> } __randomize_layout;
>
> struct inode_operations {
> --
> 2.29.2
>
>
>
prev parent reply other threads:[~2020-12-16 17:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 14:38 [PATCH] vfs, syncfs: Do not ignore return code from ->sync_fs() Vivek Goyal
2020-12-16 14:57 ` Jeff Layton
2020-12-16 15:14 ` Vivek Goyal
2020-12-16 15:44 ` Jeff Layton
2020-12-16 15:53 ` Jeff Layton
2020-12-16 17:16 ` Vivek Goyal [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=20201216171618.GB3177@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=sargun@sargun.me \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.