xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, for-linus, updated. v2.6.30-r

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.30-rc4-24279-g6c06f07
From: xfs@xxxxxxxxxxx
Date: Tue, 17 Nov 2009 11:13:41 -0600
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-linus has been updated
  6c06f07 xfs: copy li_lsn before dropping AIL lock
  8ec6dba XFS bug in log recover with quota (bugzilla id 855)
      from  a9366e61b03f55a6e009e687ad10e706714c9907 (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 6c06f072c2d797ddbb2270363de97c53ebbe0385
Author: Nathaniel W. Turner <nate@xxxxxxxxxxxxxxx>
Date:   Mon Nov 16 19:51:48 2009 +0000

    xfs: copy li_lsn before dropping AIL lock
    
    Access to log items on the AIL is generally protected by m_ail_lock;
    this is particularly needed when we're getting or setting the 64-bit
    li_lsn on a 32-bit platform.  This patch fixes a couple places where we
    were accessing the log item after dropping the AIL lock on 32-bit
    machines.
    
    This can result in a partially-zeroed log->l_tail_lsn if
    xfs_trans_ail_delete is racing with xfs_trans_ail_update, and in at
    least some cases, this can leave the l_tail_lsn with a zero cycle
    number, which means xlog_space_left will think the log is full (unless
    CONFIG_XFS_DEBUG is set, in which case we'll trip an ASSERT), leading to
    processes stuck forever in xlog_grant_log_space.
    
    Thanks to Adrian VanderSpek for first spotting the race potential and to
    Dave Chinner for debug assistance.
    
    Signed-off-by: Nathaniel W. Turner <nate@xxxxxxxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

commit 8ec6dba2581754e375be66f7bedd708d856d8b30
Author: Jan Rekorajski <baggins@xxxxxxxxxxxxxxxxx>
Date:   Mon Nov 16 11:57:02 2009 +0000

    XFS bug in log recover with quota (bugzilla id 855)
    
    Hi,
    I was hit by a bug in linux 2.6.31 when XFS is not able to recover the
    log after a crash if fs was mounted with quotas. Gory details in XFS
    bugzilla: http://oss.sgi.com/bugzilla/show_bug.cgi?id=855.
    
    It looks like wrong struct is used in buffer length check, and the following
    patch should fix the problem.
    
    xfs_dqblk_t has a size of 104+32 bytes, while xfs_disk_dquot_t is 104 bytes
    long, and this is exactly what I see in system logs - "XFS: dquot too small
    (104) in xlog_recover_do_dquot_trans."
    
    Signed-off-by: Jan Rekorajski <baggins@xxxxxxxxxxxxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_log_recover.c |    4 ++--
 fs/xfs/xfs_trans_ail.c   |   23 ++++++++++++++++++++---
 2 files changed, 22 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, for-linus, updated. v2.6.30-rc4-24279-g6c06f07, xfs <=