linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Sargun Dhillon <sargun@sargun.me>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>, Jan Kara <jack@suse.cz>,
	NeilBrown <neilb@suse.com>, Al Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@lst.de>,
	Chengguang Xu <cgxu519@mykernel.net>
Subject: Re: [PATCH 3/3] overlayfs: Report writeback errors on upper
Date: Mon, 4 Jan 2021 10:40:15 -0500	[thread overview]
Message-ID: <20210104154015.GA73873@redhat.com> (raw)
In-Reply-To: <CAOQ4uxgiC5Wm+QqD+vbmzkFvEqG6yvKYe_4sR7ZUVfu-=Ys9oQ@mail.gmail.com>

On Mon, Jan 04, 2021 at 05:22:07PM +0200, Amir Goldstein wrote:
> > > Since Jeff's patch is minimal, I think that it should be the fix applied
> > > first and proposed for stable (with adaptations for non-volatile overlay).
> >
> > Does stable fix has to be same as mainline fix. IOW, I think atleast in
> > mainline we should first fix it the right way and then think how to fix
> > it for stable. If fixes taken in mainline are not realistic for stable,
> > can we push a different small fix just for stable?
> 
> We can do a lot of things.
> But if we are able to create a series with minimal (and most critical) fixes
> followed by other fixes, it would be easier for everyone involved.

I am not sure this is really critical. writeback error reporting for
overlayfs are broken since the beginning for regular mounts. There is no
notion of these errors being reported to user space. If that did not
create a major issue, then why suddenly volatile mounts make it
a critical issue.

To me we should fix the issue properly which is easy to maintain
down the line and then worry about doing a stable fix if need be.

> 
> >
> > IOW, because we have to push a fix in stable, should not determine
> > what should be problem solution for mainline, IMHO.
> >
> 
> I find in this case there is a correlation between the simplest fix and the
> most relevant fix for stable.
> 
> > The porblem I have with Jeff's fix is that its only works for volatile
> > mounts. While I prefer a solution where syncfs() is fixed both for
> > volatile as well as non-volatile mount and then there is less confusion.
> >
> 
> I proposed a variation on Jeff's patch that covers both cases.
> Sargun is going to work on it.

What's the problem with my patches which fixes syncfs() error reporting
for overlayfs both for volatile and non-volatile mount?

Thanks
Vivek


  reply	other threads:[~2021-01-04 15:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-21 19:50 [RFC PATCH 0/3][v3] vfs, overlayfs: Fix syncfs() to return correct errors Vivek Goyal
2020-12-21 19:50 ` [PATCH 1/3] vfs: Do not ignore return code from s_op->sync_fs Vivek Goyal
2020-12-22  1:23   ` NeilBrown
2020-12-22 15:17     ` Vivek Goyal
2020-12-21 19:50 ` [PATCH 2/3] vfs: Add a super block operation to check for writeback errors Vivek Goyal
2020-12-22 16:19   ` Matthew Wilcox
2020-12-22 16:25     ` Vivek Goyal
2020-12-23 12:44       ` Jeff Layton
2020-12-23 12:48   ` Jeff Layton
2021-01-04 19:41     ` Vivek Goyal
2020-12-21 19:50 ` [PATCH 3/3] overlayfs: Report writeback errors on upper Vivek Goyal
2020-12-22 16:20   ` Matthew Wilcox
2020-12-22 16:29     ` Vivek Goyal
2020-12-22 17:46       ` Matthew Wilcox
2020-12-22 17:55         ` Vivek Goyal
2020-12-23 12:53           ` Jeff Layton
2020-12-23 18:20   ` Sargun Dhillon
2020-12-23 18:50     ` Matthew Wilcox
2020-12-23 19:29       ` Sargun Dhillon
2020-12-23 20:07         ` Matthew Wilcox
2020-12-23 20:21           ` Sargun Dhillon
2020-12-23 20:44             ` Matthew Wilcox
2020-12-24  9:32               ` Amir Goldstein
2020-12-24 10:12                 ` Sargun Dhillon
2020-12-24 12:13                 ` Matthew Wilcox
2020-12-25  6:50                   ` Amir Goldstein
2020-12-28 13:25                     ` Jeff Layton
2020-12-28 15:51                       ` Amir Goldstein
2021-01-04 15:51                         ` Vivek Goyal
2020-12-28 15:56                       ` Matthew Wilcox
2020-12-28 17:26                         ` Jeff Layton
2020-12-28 19:25                           ` Sargun Dhillon
2020-12-28 19:37                           ` Amir Goldstein
2020-12-28 20:48                             ` Matthew Wilcox
2021-01-02 13:25                               ` Jeff Layton
2021-01-04 16:59                         ` Vivek Goyal
2021-01-04 15:14                 ` Vivek Goyal
2021-01-04 15:22                   ` Amir Goldstein
2021-01-04 15:40                     ` Vivek Goyal [this message]
2021-01-04 21:42                       ` Amir Goldstein
2021-01-04 22:44                         ` Vivek Goyal
2021-01-05  7:11                           ` Amir Goldstein
2021-01-05 16:26                             ` Vivek Goyal
2021-01-05 16:57                               ` Amir Goldstein
2020-12-23 19:00     ` Jeff Layton
2021-01-04 20:00     ` Vivek Goyal

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=20210104154015.GA73873@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=cgxu519@mykernel.net \
    --cc=hch@lst.de \
    --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=neilb@suse.com \
    --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 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).