All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Naohiro Aota <Naohiro.Aota@wdc.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] btrfs: fix error handling of fallbacked uncompress write
Date: Wed, 22 Jun 2022 10:13:56 +0100	[thread overview]
Message-ID: <20220622091356.GA81185@falcondesktop> (raw)
In-Reply-To: <20220622005625.egeljuu2o423wv6y@naota-xeon>

On Wed, Jun 22, 2022 at 12:56:25AM +0000, Naohiro Aota wrote:
> On Tue, Jun 21, 2022 at 04:04:14PM +0100, Filipe Manana wrote:
> > On Tue, Jun 21, 2022 at 03:41:01PM +0900, Naohiro Aota wrote:
> > > When cow_file_range() fails in the middle of the allocation loop, it
> > > unlocks the pages but leaves the ordered extents intact. Thus, we need to
> > > call btrfs_cleanup_ordered_extents() to finish the created ordered extents.
> > > 
> > > Also, we need to call end_extent_writepage() if locked_page is available
> > > because btrfs_cleanup_ordered_extents() never process the region on the
> > > locked_page.
> > > 
> > > Furthermore, we need to set the mapping as error if locked_page is
> > > unavailable before unlocking the pages, so that the errno is properly
> > > propagated to the userland.
> > > 
> > > CC: stable@vger.kernel.org # 5.18+
> > > Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> > > ---
> > > I choose 5.18+ as the target as they are after refactoring and we can apply
> > > the series cleanly. Technically, older versions potentially have the same
> > > issue, but it might not happen actually. So, let's choose easy targets to
> > > apply.
> > > ---
> > >  fs/btrfs/inode.c | 17 +++++++++++++++--
> > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > > index 326150552e57..38d8e6d78e77 100644
> > > --- a/fs/btrfs/inode.c
> > > +++ b/fs/btrfs/inode.c
> > > @@ -933,8 +933,18 @@ static int submit_uncompressed_range(struct btrfs_inode *inode,
> > >  		goto out;
> > >  	}
> > >  	if (ret < 0) {
> > > -		if (locked_page)
> > > +		btrfs_cleanup_ordered_extents(inode, locked_page, start, end - start + 1);
> > > +		if (locked_page) {
> > > +			u64 page_start = page_offset(locked_page);
> > > +			u64 page_end = page_start + PAGE_SIZE - 1;
> > > +
> > > +			btrfs_page_set_error(inode->root->fs_info, locked_page,
> > > +					     page_start, PAGE_SIZE);
> > > +			set_page_writeback(locked_page);
> > > +			end_page_writeback(locked_page);
> > > +			end_extent_writepage(locked_page, ret, page_start, page_end);
> > >  			unlock_page(locked_page);
> > > +		}
> > >  		goto out;
> > >  	}
> > >  
> > > @@ -1383,9 +1393,12 @@ static noinline int cow_file_range(struct btrfs_inode *inode,
> > >  	 * However, in case of unlock == 0, we still need to unlock the pages
> > >  	 * (except @locked_page) to ensure all the pages are unlocked.
> > >  	 */
> > > -	if (!unlock && orig_start < start)
> > > +	if (!unlock && orig_start < start) {
> > > +		if (!locked_page)
> > > +			mapping_set_error(inode->vfs_inode.i_mapping, ret);
> > 
> > Instead of this we can pass PAGE_SET_ERROR in page_ops, which will result in
> > setting the error in the inode's mapping.
> 
> PAGE_SET_ERROR always set the error as EIO, so it cannot propagate other
> errors returned by cow_file_range() to the userland. Thus, I choose
> mapping_set_error() here.

Ok, actually only EIO and ENOSPC are used as mapping errors. mapping_set_error()
converts any error other than ENOSPC to AS_EIO. And it's been like for many years
as far as I remember.

> 
> > 
> > In fact we currently only mark the locked page with error (at writepage_delalloc()).
> 
> Yes and at submit_uncompressed_range() with this series applied.
> 
> > However all pages before and after it are still locked and we don't set the error on
> > them, I think we should - I don't see why not.
> 
> No, we unlock all pages except locked_pages in the error case, and yes, we

Yes, but by passing PAGE_SET_ERROR, we will end up setting the error bit on the
pages before unlocking them.

> set the error only on the locked_page. So, that will make the other pages
> to be writebacked later again (and make tons of the
> btrfs_writepage_fixup_work). That is common among unlock = 0 case and
> unlock = 1 case. Should we change that?

I don't see why not. But that can be done later in a separate patch, no worries.
Just something I think I didn't notice before.

Ok, the whole patchset looks good to me, thanks.

> 
> Setting all the pages as error would be good to avoid the tons of fixup in
> this case.
> 
> > Did I miss something (again)?
> > 
> > Sorry I only noticed this now.
> > 
> > Thanks.
> > 
> > >  		extent_clear_unlock_delalloc(inode, orig_start, start - 1,
> > >  					     locked_page, 0, page_ops);
> > > +	}
> > >  
> > >  	/*
> > >  	 * For the range (2). If we reserved an extent for our delalloc range
> > > -- 
> > > 2.35.1
> > > 

  reply	other threads:[~2022-06-22  9:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-21  6:40 [PATCH v2 0/4] btrfs: fix error handling of cow_file_range(unlock = 0) Naohiro Aota
2022-06-21  6:40 ` [PATCH v2 1/4] btrfs: ensure pages are unlocked on cow_file_range() failure Naohiro Aota
2022-06-21  6:41 ` [PATCH v2 2/4] btrfs: extend btrfs_cleanup_ordered_extens for NULL locked_page Naohiro Aota
2022-06-21  6:41 ` [PATCH v2 3/4] btrfs: fix error handling of fallbacked uncompress write Naohiro Aota
2022-06-21 15:04   ` Filipe Manana
2022-06-22  0:56     ` Naohiro Aota
2022-06-22  9:13       ` Filipe Manana [this message]
2022-06-21  6:41 ` [PATCH v2 4/4] btrfs: replace unnecessary goto with direct return at cow_file_range() Naohiro Aota
2022-06-22 13:58   ` David Sterba
2022-06-22  9:14 ` [PATCH v2 0/4] btrfs: fix error handling of cow_file_range(unlock = 0) Filipe Manana
2022-06-22 13:59 ` David Sterba

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=20220622091356.GA81185@falcondesktop \
    --to=fdmanana@kernel.org \
    --cc=Naohiro.Aota@wdc.com \
    --cc=linux-btrfs@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.