[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1204049492.13162.265.camel@johannes.berg>
Date: Tue, 26 Feb 2008 19:11:32 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Gaudenz Steinlin <gaudenz@...iologie.ch>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>, Christoph Hellwig <hch@....de>,
xfs-masters@....sgi.com, Eric Sandeen <sandeen@...deen.net>,
xfs@....sgi.com,
linux-kernel Mailing List <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [xfs-masters] Re: filesystem corruption on xfs after
2.6.25-rc1 (bisected, powerpc related?)
> I debuged this a bit further by testing the 4 changed functions
> individually. The problem only occurs with the new version of
> xfs_lowbit64.
Eh, uh, of course. Now that I look at that code it becomes obvious.
find_first_bit() works on unsigned longs, not 64-bit quantities, so
find_first_bit((unsigned long *)&t, 64) isn't equivalent to finding the
lowest bit set in a 64-bit quantity.
Think of the memory layout of a 64-bit word:
LE: low 32 bits | high 32 bits
BE: high 32 bits | low 32 bits
Take a look at the start of include/asm-powerpc/bitops.h, and note how
bitops don't define the memory layout at all :)
So find_first_bit(&t, 64) on BE will give you the number of the first
bit of the 32-bit rotated quantity, ie. of ((t<<32) | (t>>32)).
The problem doesn't happen with highbit64 because fls64 was specifically
coded for this purpose.
You really need to keep xfs_lowbit64 defined as it was before, or, maybe
even better, define ffs64 in parallel to fls64.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists