[Top] [All Lists]

Re: [NOISE] merge window blues, XFS broken

To: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Subject: Re: [NOISE] merge window blues, XFS broken
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 27 Jan 2014 12:56:14 +1100
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52E56386.5040802@xxxxxxxxx>
References: <52E56386.5040802@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Jan 26, 2014 at 02:35:34PM -0500, Michael L. Semon wrote:
> Hi!  This is more an observation than a bug report, me trying to figure 
> out what happened on what is now a 3-day-old kernel on 32-bit x86 
> (Pentium 4).  The report is marked as [NOISE] because I can do this...
> git pull origin master
> git remote update # updates xfs-oss
> git reset --hard v3.13
> git merge xfs-oss/master
> ...and the resulting kernel and XFS will be as smooth as silk.  
> However, if I do this...
> git pull origin master
> git remote update # at time of pull, "Already up-to-date."
> git merge xfs-oss/master
> ...the resulting XFS will not pass this, for either v4- or v5-
> superblock XFS:
> mkfs.xfs -f $TEST_DEV      # always OK
> mount $TEST_DEV $TEST_DIR  # may succeed, may fail
> ls $TEST_DIR/              # may succeed, may fail
> umount $TEST_DEV           # always fails
> The assertion is this (from notes taken by hand):
> Assertion failed: IS_ALIGNED((unsigned long)vec->i_addr, sizeof(uint64_t)), 
> file: fs/xfs/xfs_log.h, line: 49

Hmmmm - that would point to struct xfs_log_iovec being 12 bytes on
ia32, similarly the struct xfs_log_vec may not be 8 byte aligned
when allocated because pointers only require 4 byte alignement.

Hence the initial data buffer may be 4 byte aligned and so that will
break the alignment requirement.

As a test, can you add pad both structures to be a multiple of 8
bytes in size, and add to them __aligned(8) so that they are
correctly aligned in memory? i.e.

struct xfs_log_vec {
        int pad;
} __aligned(8);

struct xfs_log_iovec {
        int pad;
} __aligned(8);

And see if that makes the problem go away?

> I work with pahole maybe once every three months, and my fuzzy memory, it 
> seems like there are more holes total on 32-bit x86 than there used to be, 
> don't know why.

Check the structs with pahole before and after you make the above
padding change to see if there is a difference in size and alignment
as a result.


Dave Chinner

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