xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-12989-g579265f
From: xfs@xxxxxxxxxxx
Date: Tue, 17 Nov 2009 11:02:25 -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, master has been updated
  579265f xfs: copy li_lsn before dropping AIL lock
  e199299 XFS bug in log recover with quota (bugzilla id 855)
  5acf2d1 xfs: Wrapped journal record corruption on read at recovery
      from  943c7bf944d496529dcc41ad602b120252ac91bc (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 579265feee7a022d7c5be94d20e1c5619859a9db
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 e199299d15f5a3c42c730322f8a466209ec7d6d2
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>

commit 5acf2d19e91eb61c74eb952c7143500af45c6bad
Author: Andy Poling <andy@xxxxxxxxxxx>
Date:   Tue Nov 3 17:26:47 2009 +0000

    xfs: Wrapped journal record corruption on read at recovery
    
    Summary of problem:
    
    If a journal record wraps at the physical end of the journal, it has to be
    read in two parts in xlog_do_recovery_pass(): a read at the physical end 
and a
    read at the physical beginning.  If xlog_bread() has to re-align the first
    read, the second read request does not take that re-alignment into account.
    If the first read was re-aligned, the second read over-writes the end of the
    data from the first read, effectively corrupting it.  This can happen either
    when reading the record header or reading the record data.
    
    The first sanity check in xlog_recover_process_data() is to check for a 
valid
    clientid, so that is the error reported.
    
    Summary of fix:
    
    If there was a first read at the physical end, XFS_BUF_PTR() returns where 
the
    data was requested to begin.  Conversely, because it is the result of
    xlog_align(), offset indicates where the requested data for the first read
    actually begins - whether or not xlog_bread() has re-aligned it.
    
    Using offset as the base for the calculation of where to place the second 
read
    data ensures that it will be correctly placed immediately following the data
    from the first read instead of sometimes over-writing the end of it.
    
    The attached patch has resolved the reported problem of occasional inability
    to recover the journal (reporting "bad clientid").
    
    Signed-off-by: Andy Poling <andy@xxxxxxxxxxx>
    Reviewed-by: Alex Elder <aelder@xxxxxxx>
    Signed-off-by: Alex Elder <aelder@xxxxxxx>

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

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


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-12989-g579265f, xfs <=