All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Brian Foster <bfoster@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: restore shutdown check in mapped write fault path
Date: Wed, 10 Feb 2021 12:31:58 -0600	[thread overview]
Message-ID: <7edae48c-2ac9-94aa-8daa-a9ec3ba8907c@sandeen.net> (raw)
In-Reply-To: <20210210170112.172734-1-bfoster@redhat.com>

On 2/10/21 11:01 AM, Brian Foster wrote:
> XFS triggers an iomap warning in the write fault path due to a
> !PageUptodate() page if a write fault happens to occur on a page
> that recently failed writeback. The iomap writeback error handling
> code can clear the Uptodate flag if no portion of the page is
> submitted for I/O. This is reproduced by fstest generic/019, which
> combines various forms of I/O with simulated disk failures that
> inevitably lead to filesystem shutdown (which then unconditionally
> fails page writeback).
> 
> This is a regression introduced by commit f150b4234397 ("xfs: split
> the iomap ops for buffered vs direct writes") due to the removal of
> a shutdown check and explicit error return in the ->iomap_begin()
> path used by the write fault path. The explicit error return
> historically translated to a SIGBUS, but now carries on with iomap
> processing where it complains about the unexpected state. Restore
> the shutdown check to xfs_buffered_write_iomap_begin() to restore
> historical behavior.
> 
> Fixes: f150b4234397 ("xfs: split the iomap ops for buffered vs direct writes")
> Signed-off-by: Brian Foster <bfoster@redhat.com>

Looks good to me

Reviewed-by: Eric Sandeen <sandeen@redhat.com>

> ---
>  fs/xfs/xfs_iomap.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 70c341658c01..6594f572096e 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -860,6 +860,9 @@ xfs_buffered_write_iomap_begin(
>  	int			allocfork = XFS_DATA_FORK;
>  	int			error = 0;
>  
> +	if (XFS_FORCED_SHUTDOWN(mp))
> +		return -EIO;
> +
>  	/* we can't use delayed allocations when using extent size hints */
>  	if (xfs_get_extsz_hint(ip))
>  		return xfs_direct_write_iomap_begin(inode, offset, count,
> 

  reply	other threads:[~2021-02-10 18:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10 17:01 [PATCH] xfs: restore shutdown check in mapped write fault path Brian Foster
2021-02-10 18:31 ` Eric Sandeen [this message]
2021-02-11  1:27 ` Darrick J. Wong
2021-02-11  7:01 ` Gao Xiang

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=7edae48c-2ac9-94aa-8daa-a9ec3ba8907c@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.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.