Hello Dave, Brian,
I have posted an RFC patch, which seems to fix the issue in:
https://www.spinics.net/lists/linux-xfs/msg08895.html
Can you please review it?
I am now working on posting a patch based on 4.13-rc4, which hopefully will
make it easier to be accepted.
Thanks,
Alex.
-----Original Message-----
From: Dave Chinner
Sent: Wednesday, August 02, 2017 2:50 PM
To: Alex Lyakas
Cc: linux-xfs@xxxxxxxxxxxxxxx ; Shyam Kaushik ; bfoster@xxxxxxxxxx ;
dchinner@xxxxxxxxxx
Subject: Re: Metadata corruption at xfs_attr3_leaf_write_verify()
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@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
