From: Dave Chinner <david@fromorbit.com>
To: Alex Lyakas <alex@zadarastorage.com>
Cc: linux-xfs@vger.kernel.org,
Shyam Kaushik <shyam@zadarastorage.com>,
bfoster@redhat.com, dchinner@redhat.com
Subject: Re: Metadata corruption at xfs_attr3_leaf_write_verify()
Date: Wed, 2 Aug 2017 09:18:39 +1000 [thread overview]
Message-ID: <20170801231839.GQ17762@dastard> (raw)
In-Reply-To: <A3EABCF079964F4FA6058F30EBF80FD8@alyakaslap>
On Tue, Aug 01, 2017 at 08:30:31PM +0300, Alex Lyakas wrote:
> Greetings XFS developers, David, Brian,
>
> We did additional debugging on this issue. The problematic flow
> happens to be the following:
>
> - New inode (regular file) is being created.
> - As part of creation, due to parent directory having a default ACL,
> initial ACL is applied to the inode.
> - This ACL is applied as an extended attribute with name
> "SGI_ACL_FILE" and value length of 100 bytes.
> - XFS tries to add this attribute into the inline inode attribute
> fork area (AKA shortform).
> - But 100 bytes is too large for the shortform, so XFS creates an
> empty shortform and then calls xfs_attr_shortform_to_leaf()
> - This calls xfs_attr3_leaf_create() and creates a leaf with zero
> attributes.
> - Before XFS is able to add the attribute to the leaf, the xfsaild
> thread wants to write this leaf to disk, and trips over the assert
> in xfs_attr3_leaf_verify, that ichdr.count should not be 0
Ok, this makes it pretty obvious as to what's going on here. The new
attribute leaf buffer is not held locked across the transaction roll
between the shortform->leaf modification and the addition of the new
entry. As a result the attribute buffer modification being made is
not atomic from an operational perspective. Hence the AIL push can
grab it in the transient state of "just created" after the initial
transaction is rolled because the buffer has been released.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-08-01 23:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <d161b07cad6536b0baf285328cf99500@mail.gmail.com>
2017-08-01 17:30 ` Metadata corruption at xfs_attr3_leaf_write_verify() Alex Lyakas
2017-08-01 18:22 ` Eric Sandeen
2017-08-01 18:53 ` AW: " Markus Stockhausen
2017-08-01 18:57 ` Alex Lyakas
2017-08-01 19:02 ` Eric Sandeen
2017-08-01 23:18 ` Dave Chinner [this message]
2017-08-02 8:38 ` Alex Lyakas
2017-08-02 11:50 ` Dave Chinner
2017-08-07 14:31 ` Alex Lyakas
2017-08-07 13:55 ` Libor Klepáč
2017-08-07 14:32 ` Alex Lyakas
[not found] <CAPh1sj5oU6QRyH_cnzrkGJb6ed3XO4fGABJ4yJLPnb-ppqVJeg@mail.gmail.com>
2017-07-26 5:22 ` Shyam Kaushik
2017-07-26 12:15 ` Brian Foster
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=20170801231839.GQ17762@dastard \
--to=david@fromorbit.com \
--cc=alex@zadarastorage.com \
--cc=bfoster@redhat.com \
--cc=dchinner@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=shyam@zadarastorage.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