linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Naohiro Aota <naohiro.aota@wdc.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	linux-btrfs@vger.kernel.org, fdmanana@suse.com, clm@fb.com,
	dsterba@suse.com, jbacik@fb.com
Subject: Re: [PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents
Date: Fri, 8 Sep 2017 15:33:30 +0200	[thread overview]
Message-ID: <20170908133330.GP31874@suse.cz> (raw)
In-Reply-To: <b6a5589e-b3c4-b429-d2d8-c06c10a16abe@wdc.com>

On Fri, Sep 08, 2017 at 05:10:04PM +0900, Naohiro Aota wrote:
> On 2017年09月08日 03:25, David Sterba wrote:
> > On Fri, Sep 01, 2017 at 06:59:49PM +0800, Qu Wenruo wrote:
> >> On 2017年09月01日 16:58, Naohiro Aota wrote:
> >>> commit 524272607e88 ("btrfs: Handle delalloc error correctly to avoid
> >>> ordered extent hang") introduced btrfs_cleanup_ordered_extents() to cleanup
> >>> submitted ordered extents. However, it does not clear the ordered bit
> >>> (Private2) of coresponding pages. Thus, the following BUG occurs from
> >>> free_pages_check_bad() (on btrfs/125 with nospace_cache).
> >>>
> >>> BUG: Bad page state in process btrfs  pfn:3fa787
> >>> page:ffffdf2acfe9e1c0 count:0 mapcount:0 mapping:          (null) index:0xd
> >>> flags: 0x8000000000002008(uptodate|private_2)
> >>> raw: 8000000000002008 0000000000000000 000000000000000d 00000000ffffffff
> >>> raw: ffffdf2acf5c1b20 ffffb443802238b0 0000000000000000 0000000000000000
> >>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> >>> bad because of flags: 0x2000(private_2)
> >>>
> >>> This patch clear the flag as same as other places calling
> >>> btrfs_dec_test_ordered_pending() for every page in the specified range.
> >>>
> >>> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> >>> Fixes: 524272607e88 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang")
> >>> Cc: <stable@vger.kernel.org> # 4.12
> >>> ---
> >>>   fs/btrfs/inode.c |   12 ++++++++++++
> >>>   1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> >>> index 24bcd5cd9cf2..ae4c0a1bef38 100644
> >>> --- a/fs/btrfs/inode.c
> >>> +++ b/fs/btrfs/inode.c
> >>> @@ -135,6 +135,18 @@ static inline void btrfs_cleanup_ordered_extents(struct inode *inode,
> >>>   						 const u64 offset,
> >>>   						 const u64 bytes)
> >>>   {
> >>> +	unsigned long index = offset >> PAGE_SHIFT;
> >>> +	unsigned long end_index = (offset + bytes - 1) >> PAGE_SHIFT;
> >>> +	struct page *page;
> >>> +
> >>> +	while (index <= end_index) {
> >>> +		page = find_get_page(inode->i_mapping, index);
> >>> +		index++;
> >>> +		if (!page)
> >>> +			continue;
> >>> +		ClearPagePrivate2(page);
> >>> +		put_page(page);
> >>> +	}
> >>
> >> At first glance, explicitly clearing Private2 flag here seems a little 
> >> strange to me.
> >> However btrfs_invalidatepage() is also doing the same thing, I think 
> >> it's fine.
> >>
> >> Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
> >>
> >> BTW, Private2 flag is set by extent_clear_unlock_delalloc() with 
> >> page_ops |= PAGE_SET_PRIVATE2, but we're clearing the page flag without 
> >> any encapsulation, it may be better to use similar function to clear 
> >> Private2 flag.
> > 
> > I agree, the Private2 flag is given another meaning in btrfs, ie. the
> > writeback status, so this would be better wrapped in helpers that
> > reflect what is the private2 flag used for. The helpers might be
> > trivial, but their name will be a better documentation than the random
> > comments that we can be found next to its use.
> > 
> 
> Thanks for the reviews. I'll send a new patch to add the wrapping
> function. (or should I squash the patch with this change?)

Please send a separate patch.

  reply	other threads:[~2017-09-08 13:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-01  8:58 [PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents Naohiro Aota
2017-09-01  8:59 ` [PATCH 2/2] btrfs: finish ordered extent cleaning if no progress is found Naohiro Aota
2017-09-01 11:31   ` Qu Wenruo
2017-09-07 18:16     ` David Sterba
2017-09-01 12:38   ` Josef Bacik
2017-09-01 10:59 ` [PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents Qu Wenruo
2017-09-07 18:25   ` David Sterba
2017-09-08  8:10     ` Naohiro Aota
2017-09-08 13:33       ` David Sterba [this message]
2017-09-01 12:38 ` Josef Bacik

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=20170908133330.GP31874@suse.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=fdmanana@suse.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=quwenruo.btrfs@gmx.com \
    /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).