[Top] [All Lists]

[XFS updates] XFS development tree branch, master, updated. v3.10-rc1-30

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, master, updated. v3.10-rc1-30-g8a1fd29
From: xfs@xxxxxxxxxxx
Date: Thu, 13 Jun 2013 10:57:17 -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, master has been updated
  8a1fd29 xfs: fix implicit padding in directory and attr CRC formats
      from  5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 (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 8a1fd2950e1fe267e11fc8c85dcaa6b023b51b60
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Wed Jun 12 12:19:07 2013 +1000

    xfs: fix implicit padding in directory and attr CRC formats
    Michael L. Semon has been testing CRC patches on a 32 bit system and
    been seeing assert failures in the directory code from xfs/080.
    Thanks to Michael's heroic efforts with printk debugging, we found
    that the problem was that the last free space being left in the
    directory structure was too small to fit a unused tag structure and
    it was being corrupted and attempting to log a region out of bounds.
    Hence the assert failure looked something like:
    #5 calling xfs_dir2_data_log_unused() 36 32
    #1 4092 4095 4096
    #2 8182 8183 4096
    XFS: Assertion failed: first <= last && last < BBTOB(bp->b_length), file: 
fs/xfs/xfs_trans_buf.c, line: 568
    Where #1 showed the first region of the dup being logged (i.e. the
    last 4 bytes of a directory buffer) and #2 shows the corrupt values
    being calculated from the length of the dup entry which overflowed
    the size of the buffer.
    It turns out that the problem was not in the logging code, nor in
    the freespace handling code. It is an initial condition bug that
    only shows up on 32 bit systems. When a new buffer is initialised,
    where's the freespace that is set up:
    [  172.316249] calling xfs_dir2_leaf_addname() from xfs_dir_createname()
    [  172.316346] #9 calling xfs_dir2_data_log_unused()
    [  172.316351] #1 calling xfs_trans_log_buf() 60 63 4096
    [  172.316353] #2 calling xfs_trans_log_buf() 4094 4095 4096
    Note the offset of the first region being logged? It's 60 bytes into
    the buffer. Once I saw that, I pretty much knew that the bug was
    going to be caused by this.
    Essentially, all direct entries are rounded to 8 bytes in length,
    and all entries start with an 8 byte alignment. This means that we
    can decode inplace as variables are naturally aligned. With the
    directory data supposedly starting on a 8 byte boundary, and all
    entries padded to 8 bytes, the minimum freespace in a directory
    block is supposed to be 8 bytes, which is large enough to fit a
    unused data entry structure (6 bytes in size). The fact we only have
    4 bytes of free space indicates a directory data block alignment
    And what do you know - there's an implicit hole in the directory
    data block header for the CRC format, which means the header is 60
    byte on 32 bit intel systems and 64 bytes on 64 bit systems. Needs
    padding. And while looking at the structures, I found the same
    problem in the attr leaf header. Fix them both.
    Note that this only affects 32 bit systems with CRCs enabled.
    Everything else is just fine. Note that CRC enabled filesystems created
    before this fix on such systems will not be readable with this fix
    Reported-by: Michael L. Semon <mlsemon35@xxxxxxxxx>
    Debugged-by: Michael L. Semon <mlsemon35@xxxxxxxxx>
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Ben Myers <bpm@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>


Summary of changes:
 fs/xfs/xfs_attr_leaf.h   | 1 +
 fs/xfs/xfs_dir2_format.h | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, master, updated. v3.10-rc1-30-g8a1fd29, xfs <=