All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC formats
Date: Wed, 12 Jun 2013 21:40:47 -0400	[thread overview]
Message-ID: <51B9231F.9050707@gmail.com> (raw)
In-Reply-To: <20130613005819.GW20932@sgi.com>

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@redhat.com>
>>
>> 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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-06-13  1:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12  2:19 [PATCH 0/3] xfs: fixes for 3.10-rc6 Dave Chinner
2013-06-12  2:19 ` [PATCH 1/3] xfs: don't shutdown log recovery on validation errors Dave Chinner
2013-06-13  1:04   ` Ben Myers
2013-06-13  2:08     ` Dave Chinner
2013-06-13 22:09       ` Ben Myers
2013-06-14  0:13         ` Dave Chinner
2013-06-14 12:55           ` Mark Tinguely
2013-06-14 16:09           ` Ben Myers
2013-06-14 16:15             ` Eric Sandeen
2013-06-14 19:08               ` Ben Myers
2013-06-14 19:18                 ` Eric Sandeen
2013-06-14 19:44                   ` Ben Myers
2013-06-14 19:54                     ` Eric Sandeen
2013-06-14 20:22                       ` Ben Myers
2013-06-28 18:54                         ` Dave Jones
2013-06-28 19:24                           ` Ben Myers
2013-06-28 19:28                             ` Dave Jones
2013-06-28 19:31                               ` Ben Myers
2013-06-15  0:56                     ` Dave Chinner
2013-06-17 14:53                       ` Ben Myers
2013-06-18  1:22                         ` Dave Chinner
2013-06-14 16:17             ` Dave Jones
2013-06-14 16:31               ` Ben Myers
2013-06-12  2:19 ` [PATCH 2/3] xfs: fix implicit padding in directory and attr CRC formats Dave Chinner
2013-06-13  0:58   ` Ben Myers
2013-06-13  1:40     ` Michael L. Semon [this message]
2013-06-13  2:27     ` Dave Chinner
2013-06-13 21:31       ` Ben Myers
2013-06-12  2:19 ` [PATCH 3/3] xfs: ensure btree root split sets blkno correctly Dave Chinner
2013-06-13 19:16   ` Ben Myers
2013-06-14  0:21     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51B9231F.9050707@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=bpm@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.