All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Matthew Wilcox <willy@infradead.org>,
	"Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: question about mapping_set_error when writeback fails?
Date: Thu, 03 Jun 2021 14:02:08 -0400	[thread overview]
Message-ID: <589c225884ced126b0ff52f419686fa6d185c5c8.camel@kernel.org> (raw)
In-Reply-To: <YLgFpqi63K/NMO2D@casper.infradead.org>

On Wed, 2021-06-02 at 23:26 +0100, Matthew Wilcox wrote:
> On Wed, Jun 02, 2021 at 01:27:56PM -0700, Darrick J. Wong wrote:
> > In iomap_finish_page_writeback,
> > 
> > static void
> > iomap_finish_page_writeback(struct inode *inode, struct page *page,
> > 		int error, unsigned int len)
> > {
> > 	struct iomap_page *iop = to_iomap_page(page);
> > 
> > 	if (error) {
> > 		SetPageError(page);
> > 		mapping_set_error(inode->i_mapping, -EIO);
> > 
> > Why don't we pass error to mapping_set_error here?  If the writeback
> > completion failed due to insufficient space (e.g. extent mapping btree
> > expansion hit ENOSPC while trying to perform an unwritten extent
> > conversion) then we set AS_EIO which causes fsync to return EIO instead
> > of ENOSPC like you'd expect.
> 
> Hah, I noticed the same thing a few weeks ago and didn't get round to
> asking about it yet.  I'm pretty sure we should pass the real error to
> mapping_set_error().
> 
> I also wonder if we shouldn't support more of the errors from
> blk_errors, like -ETIMEDOUT or -EILSEQ, but that's a different
> conversation.

Note that whatever error you pass there is likely to bubble up to
userland via fsync/msync or whatever. Most file_check_and_advance_wb_err
callers don't vet that return code in any way. That's not a problem,
per-se, but you should be aware of the potential effects.
-- 
Jeff Layton <jlayton@kernel.org>


      reply	other threads:[~2021-06-03 18:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 20:27 question about mapping_set_error when writeback fails? Darrick J. Wong
2021-06-02 22:26 ` Matthew Wilcox
2021-06-03 18:02   ` Jeff Layton [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=589c225884ced126b0ff52f419686fa6d185c5c8.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.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.