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.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|