[Top] [All Lists]

[XFS updates] XFS development tree branch, for-next, updated. v3.9-rc1-1

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, for-next, updated. v3.9-rc1-18-g666d644
From: xfs@xxxxxxxxxxx
Date: Fri, 5 Apr 2013 13:29:51 -0500 (CDT)
Delivered-to: xfs@xxxxxxxxxxx
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-next has been updated
  666d644 xfs: don't free EFIs before the EFDs are committed
  3d6e036 xfs: Add ratelimited printk for different alert levels
      from  ff9a28f6c25d18a635abcab1f49db68108203dfb (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 666d644cd72a9ec58b353209ff191d7430f3b357
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Wed Apr 3 14:09:21 2013 +1100

    xfs: don't free EFIs before the EFDs are committed
    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, and 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
    What we really want is this: the EFI is always placed into the
    AIL before the last reference goes away. The only way to guarantee
    that is that the EFI is not freed until after it has been unpinned
    *and* the EFD has been committed. That is, restructure the logic so
    that the only case that can occur is the first case.
    This can be done easily by replacing the XFS_EFI_COMMITTED with an
    EFI reference count. The EFI is initialised with it's own count, and
    that is not released until it is unpinned. However, there is a
    complication to this method - the high level EFI/EFD code in
    xfs_bmap_finish() does not hold direct references to the EFI
    structure, and runs a transaction commit between the EFI and EFD
    processing. Hence the EFI can be freed even before the EFD is
    created using such a method.
    Further, log recovery uses the AIL for tracking EFI/EFDs that need
    to be recovered, but it uses the AIL *differently* to the EFI
    transaction commit. Hence log recovery never pins or unpins EFIs, so
    we can't drop the EFI reference count indirectly to free the EFI.
    However, this doesn't prevent us from using a reference count here.
    There is a 1:1 relationship between EFIs and EFDs, so when we
    initialise the EFI we can take a reference count for the EFD as
    well. This solves the xfs_bmap_finish() issue - the EFI will never
    be freed until the EFD is processed. In terms of log recovery,
    during the committing of the EFD we can look for the
    XFS_EFI_RECOVERED bit being set and drop the EFI reference as well,
    thereby ensuring everything works correctly there as well.
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

commit 3d6e036193bfa67a8a1cc1908fe910c7a014d183
Author: Rich Johnston <rjohnston@xxxxxxx>
Date:   Wed Mar 27 09:26:49 2013 -0500

    xfs: Add ratelimited printk for different alert levels
    Ratelimited printk will be useful in printing xfs messages which are 
    not required to be printed always due to their high rate (to prevent kernel 
    buffer from overflowing), while at the same time required to be printed.
    Signed-off-by: Raghavendra D Prabhu <rprabhu@xxxxxxxxxxx>
    Reviewed-by: Rich Johnston <rjohnston@xxxxxxx>
    Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>


Summary of changes:
 fs/xfs/xfs_extfree_item.c | 27 +++++++++++++--------------
 fs/xfs/xfs_extfree_item.h | 14 +++++++++-----
 fs/xfs/xfs_linux.h        |  1 +
 fs/xfs/xfs_log_recover.c  |  1 +
 fs/xfs/xfs_message.h      | 26 ++++++++++++++++++++++++++
 5 files changed, 50 insertions(+), 19 deletions(-)

XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, for-next, updated. v3.9-rc1-18-g666d644, xfs <=