From: Liu Bo <bo.li.liu@oracle.com>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Filipe Manana <fdmanana@gmail.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty
Date: Wed, 7 Sep 2016 14:36:02 -0700 [thread overview]
Message-ID: <20160907213601.GA15742@localhost.localdomain> (raw)
In-Reply-To: <4c163cdc-e736-55b5-88b2-5d47bcd4f554@suse.com>
Hi Jeff,
On Wed, Sep 07, 2016 at 10:25:54AM -0400, Jeff Mahoney wrote:
> On 9/6/16 5:51 PM, Liu Bo wrote:
> > Hi Filipe,
> >
> > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote:
> >> On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo <bo.li.liu@oracle.com> wrote:
> >>> This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y.
> >>>
> >>> Commit 1ba98d0 ("Btrfs: detect corruption when non-root leaf has zero item")
> >>> assumes that a leaf is its root when leaf->bytenr == btrfs_root_bytenr(root),
> >>> however, we should not use btrfs_root_bytenr(root) since it's mainly got
> >>> updated during committing transaction. So the check can fail when doing
> >>> COW on this leaf while it is a root.
> >>>
> >>> This changes to use "if (leaf == btrfs_root_node(root))" instead, just like
> >>> how we check whether leaf is a root in __btrfs_cow_block().
> >>>
> >>> Reported-by: Jeff Mahoney <jeffm@suse.com>
> >>> Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> >>
> >> Hi Bo,
> >>
> >> Even with this patch applied against latest branch for-linus-4.8, at
> >> least on a build with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y,
> >> the issue still happens for me when running fsstress with balance in parallel:
> >
> > Thanks for the report.
> >
> > This panic shows that we can have non-root btree leaf with 0 nritems during
> > split_leaf(), but a btrfs_search_slot which calls split_leaf() like this is
> > inserting an item, and while we set @right's nritems to 0, we also assign @disk_key
> > associated with @right in the parent node, so I think we're actually having
> > nritem 0 temporarily and we can remove this btrfs_mark_buffer_dirty() like the
> > following quick patch.
> >
> > Thanks,
> >
> > -liubo
> >
> > diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> > index d1c56c9..5e5ceb5 100644
> > --- a/fs/btrfs/ctree.c
> > +++ b/fs/btrfs/ctree.c
> > @@ -4341,7 +4341,11 @@ again:
> > if (path->slots[1] == 0)
> > fixup_low_keys(fs_info, path, &disk_key, 1);
> > }
> > - btrfs_mark_buffer_dirty(right);
> > + /*
> > + * We create a new leaf 'right' for the required ins_len and
> > + * we'll do btrfs_mark_buffer_dirty() on this leaf after copying
> > + * the content of ins_len to 'right'.
> > + */
> > return ret;
> > }
> >
> >
> >
>
> I think you're on the right track here. I need to see if I still have
> the code lying around, but when I was debugging the btrfs_rename issue
> that ended up being a compiler bug, I hooked into check_leaf and ran
> into similar issues. We mark the buffer dirty before it's in a
> consistent state.
That's right.
One thing that I'm not 100% sure is that if there is a
chance that this metadata leaf gets flushed by writeback throttle code
and we panic after it so that we get a 'nritem 0 non-root' leaf, no?
But anyway, even if we have it, we'd know it by the newly added check
in check_leaf.
Thanks,
-liubo
next prev parent reply other threads:[~2016-09-07 21:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 4:57 [PATCH] Btrfs: detect corruption when non-root leaf has zero item Liu Bo
2016-08-16 17:07 ` David Sterba
2016-08-22 0:04 ` Liu Bo
2016-08-23 22:22 ` [PATCH v2] " Liu Bo
2016-08-24 11:51 ` David Sterba
2016-09-02 5:26 ` Jeff Mahoney
2016-09-02 19:33 ` Liu Bo
2016-09-02 19:35 ` [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty Liu Bo
2016-09-05 15:28 ` Filipe Manana
2016-09-06 21:51 ` Liu Bo
2016-09-07 14:25 ` Jeff Mahoney
2016-09-07 21:36 ` Liu Bo [this message]
2016-10-12 21:23 ` Filipe Manana
2016-10-13 0:37 ` Liu Bo
2016-10-13 8:47 ` Filipe Manana
2016-10-17 13:00 ` David Sterba
2016-10-17 15:44 ` Liu Bo
2016-11-23 13:15 ` Filipe Manana
2016-11-23 17:48 ` Filipe Manana
2016-11-23 21:39 ` Liu Bo
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=20160907213601.GA15742@localhost.localdomain \
--to=bo.li.liu@oracle.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@gmail.com \
--cc=jeffm@suse.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.