xfs
[Top] [All Lists]

Re: [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC form

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC formats
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Wed, 12 Jun 2013 21:40:47 -0400
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6gEFgjg/ojhmOoMUp9Y+keae7bYGJRpVsrHy8vjuf1k=; b=KRyen4XiJll1TxF+GoVPGoo1eyg+hsGTpSgGYAFVWQtEO8aUf8XZXp2zPSLx0Cg7vg ZMOL0GxB9A7zavak4h9VW0jpQWDOv+B6Q4WS6bBhqnw67ndH7DDAodAF4W6MUOr1iwv8 6Qy8TFYV3cTj889/L1ZEQLWQIyR8NAcOafMyk3ebAGpAGRYmE21ZNo3ALW0S5XLjql8O CaXbtD4m7l7xa5FIMKLBbiZFZtR7v2ggs1qG7Ek3OGQylhbjGwIqngimtM7GyxvYD66Y EPL8h6f6FsI6dpwJdUcv5WIfG8dMLUDRL1tbjY71AlgPWh3rZ0t95cDhIHf+eKcbMzMH mAhw==
In-reply-to: <20130613005819.GW20932@xxxxxxx>
References: <1371003548-4026-1-git-send-email-david@xxxxxxxxxxxxx> <1371003548-4026-3-git-send-email-david@xxxxxxxxxxxxx> <20130613005819.GW20932@xxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
On 06/12/2013 08:58 PM, Ben Myers wrote:
> On Wed, Jun 12, 2013 at 12:19:07PM +1000, Dave Chinner wrote:
>> From: Dave Chinner <dchinner@xxxxxxxxxx>
>>
>> Michael L. Semon has been testing CRC patches ona 32 bit system and
>                                               on a
> 
>> 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
>      first? 
>           last?
>                bp->b_length?

           BBTOB(bp->b_length)

This is all terrible numbering on my part...

>> #1 4092 4095 4096
>> #2 8182 8183 4096

xfs_dir2_data_log_unused() calls xfs_trans_log_buf() twice in the same 
function.  #1 is the first call, #2 is the second call, and there's no 
running count.  The printk() is a copy-and-paste of those two function 
calls plus a BBTOB(bp->b_length) below it.

>> #5 calling xfs_dir2_data_log_unused() 36 32

The #5 was caused by numbering all the calls to 
xfs_dir2_data_log_unused() to see if one code path was being called 
every time.  #5 is in the xfs_dir2_data_use_free() function, starting 
with this else-if...

        else if (matchfront) {
                newdup = (xfs_dir2_data_unused_t *)((char *)hdr + offset + len);
                newdup->freetag = cpu_to_be16(XFS_DIR2_DATA_FREE_TAG);
                newdup->length = cpu_to_be16(oldlen - len);
                *xfs_dir2_data_unused_tag_p(newdup) =
                        cpu_to_be16((char *)newdup - (char *)hdr);
                printk( KERN_INFO "#5 calling xfs_dir2_data_log_unused() %d 
%d\n", oldlen, len );
                xfs_dir2_data_log_unused(tp, bp, newdup);

Sorry about that!

Michael

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