* [PATCH-possible bugfix] xfs: ensure extents are read as be64
@ 2008-04-15 3:28 Harvey Harrison
2008-04-15 4:58 ` David Chinner
0 siblings, 1 reply; 3+ messages in thread
From: Harvey Harrison @ 2008-04-15 3:28 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton; +Cc: LKML
The debug code reads the extents in cpu-order rather than BE. Make the
debug code match.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Possibly 2.6.25 material....if it actually is a bug. See elsewhere
in the same file that reads as be64. (look for ep->l0).
fs/xfs/xfs_inode.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index f43a6e0..eacf2ca 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -85,8 +85,8 @@ xfs_validate_extents(
for (i = 0; i < nrecs; i++) {
xfs_bmbt_rec_host_t *ep = xfs_iext_get_ext(ifp, i);
- rec.l0 = get_unaligned(&ep->l0);
- rec.l1 = get_unaligned(&ep->l1);
+ rec.l0 = be64_to_cpu(get_unaligned(&ep->l0));
+ rec.l1 = be64_to_cpu(get_unaligned(&ep->l1));
xfs_bmbt_get_all(&rec, &irec);
if (fmt == XFS_EXTFMT_NOSTATE)
ASSERT(irec.br_state == XFS_EXT_NORM);
--
1.5.5.144.g3e42
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH-possible bugfix] xfs: ensure extents are read as be64
2008-04-15 3:28 [PATCH-possible bugfix] xfs: ensure extents are read as be64 Harvey Harrison
@ 2008-04-15 4:58 ` David Chinner
2008-04-15 5:03 ` Harvey Harrison
0 siblings, 1 reply; 3+ messages in thread
From: David Chinner @ 2008-04-15 4:58 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Christoph Hellwig, Andrew Morton, LKML
On Mon, Apr 14, 2008 at 08:28:51PM -0700, Harvey Harrison wrote:
> The debug code reads the extents in cpu-order rather than BE. Make the
> debug code match.
xfs_validate_extents() is reading in-core extents which have already
been byte-swapped when they were read into memory.
FWIW, when changing anything to do with endian conversion, please
ensure you run:
$ make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
over the change. This change would introduce errors because:
typedef struct xfs_bmbt_rec_host {
__uint64_t l0, l1;
} xfs_bmbt_rec_host_t;
is not defined with __beXX types like the disk format version of this
structure which is:
typedef struct xfs_bmbt_rec_64 {
__be64 l0, l1;
} xfs_bmbt_rec_64_t;
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH-possible bugfix] xfs: ensure extents are read as be64
2008-04-15 4:58 ` David Chinner
@ 2008-04-15 5:03 ` Harvey Harrison
0 siblings, 0 replies; 3+ messages in thread
From: Harvey Harrison @ 2008-04-15 5:03 UTC (permalink / raw)
To: David Chinner; +Cc: Christoph Hellwig, Andrew Morton, LKML
On Tue, 2008-04-15 at 14:58 +1000, David Chinner wrote:
> On Mon, Apr 14, 2008 at 08:28:51PM -0700, Harvey Harrison wrote:
> > The debug code reads the extents in cpu-order rather than BE. Make the
> > debug code match.
>
> xfs_validate_extents() is reading in-core extents which have already
> been byte-swapped when they were read into memory.
>
> FWIW, when changing anything to do with endian conversion, please
> ensure you run:
>
> $ make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
>
> over the change. This change would introduce errors because:
>
> typedef struct xfs_bmbt_rec_host {
> __uint64_t l0, l1;
> } xfs_bmbt_rec_host_t;
>
> is not defined with __beXX types like the disk format version of this
> structure which is:
>
> typedef struct xfs_bmbt_rec_64 {
> __be64 l0, l1;
> } xfs_bmbt_rec_64_t;
>
Sorry for the noise, I didn't notice the (slightly) different struct
types. Just the very similar looking blocks in both functions.
My Bad,
Harvey
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-04-15 5:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-15 3:28 [PATCH-possible bugfix] xfs: ensure extents are read as be64 Harvey Harrison
2008-04-15 4:58 ` David Chinner
2008-04-15 5:03 ` Harvey Harrison
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox