All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 08/11] cifs: Remove call to filemap_check_wb_err()
Date: Mon, 09 Jan 2023 10:14:12 -0500	[thread overview]
Message-ID: <74c40f813d4dc2bf90fbf80a80a5f0ba15365a90.camel@redhat.com> (raw)
In-Reply-To: <7d1499fadf42052711e39f0d8c7656f4d3a4bc9d.camel@redhat.com>

On Mon, 2023-01-09 at 09:42 -0500, Jeff Layton wrote:
> On Mon, 2023-01-09 at 05:18 +0000, Matthew Wilcox (Oracle) wrote:
> > filemap_write_and_wait() now calls filemap_check_wb_err(), so we cannot
> > glean any additional information by calling it ourselves.  It may also
> > be misleading as it will pick up on any errors since the beginning of
> > time which may well be since before this program opened the file.
> > 
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > ---
> >  fs/cifs/file.c | 8 +++-----
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> > index 22dfc1f8b4f1..7e7ee26cf77d 100644
> > --- a/fs/cifs/file.c
> > +++ b/fs/cifs/file.c
> > @@ -3042,14 +3042,12 @@ int cifs_flush(struct file *file, fl_owner_t id)
> >  	int rc = 0;
> >  
> >  	if (file->f_mode & FMODE_WRITE)
> > -		rc = filemap_write_and_wait(inode->i_mapping);
> > +		rc = filemap_write_and_wait(file->f_mapping);
> 
> If we're calling ->flush, then the file is being closed. Should this
> just be?
> 		rc = file_write_and_wait(file);
> 
> It's not like we need to worry about corrupting ->f_wb_err at that
> point.
> 

OTOH, I suppose it is possible for there to be racing fsync syscall with
a filp_close, and in that case advancing the f_wb_err might be a bad
idea, particularly since a lot of places ignore the return from
filp_close. It's probably best to _not_ advance the f_wb_err on ->flush
calls.

That said...wonder if we ought to consider making filp_close and ->flush
void return functions. There's no POSIX requirement to flush all of the
data on close(), so an application really shouldn't rely on seeing
writeback errors returned there since it's not reliable.

If you care about writeback errors, you have to call fsync -- full stop.

> >  
> >  	cifs_dbg(FYI, "Flush inode %p file %p rc %d\n", inode, file rc);
> > -	if (rc) {
> > -		/* get more nuanced writeback errors */
> > -		rc = filemap_check_wb_err(file->f_mapping, 0);
> > +	if (rc)
> >  		trace_cifs_flush_err(inode->i_ino, rc);
> > -	}
> > +
> >  	return rc;
> >  }
> >  
> 

-- 
Jeff Layton <jlayton@redhat.com>


  parent reply	other threads:[~2023-01-09 15:16 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09  5:18 [PATCH 00/11] Remove AS_EIO and AS_ENOSPC Matthew Wilcox (Oracle)
2023-01-09  5:18 ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 01/11] memory-failure: Remove comment referencing AS_EIO Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-12  8:31   ` Christoph Hellwig
2023-01-09  5:18 ` [PATCH 02/11] filemap: Remove filemap_check_and_keep_errors() Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09 13:48   ` Jeff Layton
2023-01-09 14:02     ` Matthew Wilcox
2023-01-09 14:31       ` Jeff Layton
2023-01-09 15:02         ` Matthew Wilcox
2023-01-09  5:18 ` [PATCH 03/11] f2fs: Convert f2fs_wait_on_node_pages_writeback() to errseq Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 04/11] fuse: Convert fuse_flush() to use file_check_and_advance_wb_err() Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09 15:25   ` Jeff Layton
2023-01-09  5:18 ` [PATCH 05/11] page-writeback: Convert folio_write_one() to use an errseq Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 06/11] filemap: Convert filemap_write_and_wait_range() to use errseq Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-17  2:55   ` kernel test robot
2023-01-09  5:18 ` [PATCH 07/11] filemap: Convert filemap_fdatawait_range() to errseq Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 08/11] cifs: Remove call to filemap_check_wb_err() Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09 14:42   ` Jeff Layton
2023-01-09 15:07     ` Matthew Wilcox
2023-01-09 15:14     ` Jeff Layton [this message]
2023-01-09 15:30       ` Matthew Wilcox
2023-01-09 15:43         ` Jeff Layton
2023-01-09  5:18 ` [PATCH 09/11] mm: Remove AS_EIO and AS_ENOSPC Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 10/11] mm: Remove filemap_fdatawait_range_keep_errors() Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09  5:18 ` [PATCH 11/11] mm: Remove filemap_fdatawait_keep_errors() Matthew Wilcox (Oracle)
2023-01-09  5:18   ` Matthew Wilcox (Oracle)
2023-01-09 15:31 ` [PATCH 00/11] Remove AS_EIO and AS_ENOSPC Jeff Layton
2023-01-12  8:30 ` Christoph Hellwig

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=74c40f813d4dc2bf90fbf80a80a5f0ba15365a90.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.