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 21:50:30 +1000 [thread overview]
Message-ID: <20170802115030.GS17762@dastard> (raw)
In-Reply-To: <7AF4FEF16E034B868577B3ED535D5C41@alyakaslap>
On Wed, Aug 02, 2017 at 11:38:36AM +0300, Alex Lyakas wrote:
> Hello Dave,
>
> Thank you for your analysis. It sounds like this issue exists in
> recent kernels as well.
It's effectively a zero day bug. The two-transaction conversion to
leaf form is recognisable in this commit from Jun 1995:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=archive/xfs-import.git;a=commitdiff;h=d4e0d38051ce61f9d8f330f59e0a99ed710d5f9e
This was about a month after attr support first shows up in the XFS
commit history, so it's been there forever....
> We are reviewing some of the paths that operate xfs_buf's, but still
> we don't have enough understanding on how to properly lock out the
> xfs_buf from AIL grabbing it. Can you please point us at similar
> flows, where such locking is done?
It's simple - if the buffer is locked, the AIL can't grab it. The
buffer needs to be held locked across transaction commit
and then rejoined to the new transaction after it is rolled. THis is
acheived by using xfs_trans_bhold() in the initial transaction
context, and after commit it is rejoined to the new transaction
context.
See the inode chunk allocation code in xfs_dir_ialloc() for an
example of how this works.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-08-02 11:50 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
2017-08-02 8:38 ` Alex Lyakas
2017-08-02 11:50 ` Dave Chinner [this message]
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=20170802115030.GS17762@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