[Top] [All Lists]

Re: [PATCH] xfs: don't free EFIs before the EFDs are committed

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: don't free EFIs before the EFDs are committed
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Wed, 03 Apr 2013 14:12:09 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1364958561-12440-1-git-send-email-david@xxxxxxxxxxxxx>
References: <1364958561-12440-1-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 04/02/13 22:09, Dave Chinner wrote:
From: Dave Chinner<dchinner@xxxxxxxxxx>

Filesystems are occasionally being shut down with this error:

xfs_trans_ail_delete_bulk: attempting to delete a log item that is
not in the AIL.

It was diagnosed to be related to the EFI/EFD commit order when the
EFI and EFD are in different checkpoints and the EFD is committed
before the EFI here:


The real problem is that a single bit cannot fully describe the
states that the EFI/EFD processing can be in. These completion
states are:

EFI                     EFI in AIL      EFD             Result
committed/unpinned      Yes             committed       OK
committed/pinned        No              committed       Shutdown
uncommitted             No              committed       Shutdown

Note that the "result" field is what should happen, not what does
happen. The current logic is broken and handles the first two cases
correctly by luck.  That is, the code will free the EFI if the
XFS_EFI_COMMITTED bit is*not*  set, rather than if it is set. The
inverted logic "works" because if both EFI and EFD are committed,
then the first __xfs_efi_release() call clears the XFS_EFI_COMMITTED
bit, and the second frees the EFI item. Hence as long as
xfs_efi_item_committed() has been called, everything appears to be

It is the third case where the logic fails - where
xfs_efd_item_committed() is called before xfs_efi_item_committed(),
and that results in the EFI being freed before it has been
committed. That is the bug that triggered the shutdown, d hence
keeping track of whether the EFI has been committed or not is
insufficient to correctly order the EFI/EFD operations w.r.t. the

I think the exist xfs_efi routines are working correctly.

the xfs_trans_committed_bulk() for the efi does the IOP_COMMITTED (sets the XFS_EFI_COMMITTED bit), add the entry to the AIL and then an IOP_UNPIN() which clears the XFS_EFI_COMMITTED since it is set, it should not release the efi and remove the entry from the AIL. It also correctly detects if the EFD is committed before the EFI by shutting down the filesystem.

This patch seems to paper over why the EFD will come before the EFI.

The CIL commits are in the correct order - protected by the xlog_wait() but the callbacks are out of order.

My previous patch fixed the callback from happening out of sequence.


<Prev in Thread] Current Thread [Next in Thread>