Re: [PATCH] xfs: read rmapbt high key offsets with get_unaligned() in scrub

[Dave Chinner <dgc@kernel.org>]

On Tue, Nov 10, 2026 at 09:33:46AM +0100, Stian Halseth wrote:
> Hi Dave,
> 
> On Tue, 2026-11-10 at 08:40 +1100, Dave Chinner wrote:
> > 
> > That just looks wrong to begin with. Decoding an on-disk structure
> > without using be64_to_cpu() to get it in the correct endian order
> > first?
> > 
> > Oh... the code plays "I'm too smart for my own good" micro-
> > optimisation games by endian swapping the badflag variable to avoid
> > needing to endian swap the rm_offset field.
> > 
> > It seems to me that the correct fix here is to stop endian swapping
> > the badflag variable, and endian swap the rmap.rm_offset fetches for
> > both the low key and high keys, like all the other places that
> > dereference rmap.rm_offset direct from pointers returned by
> > xfs_btree_key_addr()/xfs_btree_high_key_addr().
> > 
> 
> Thanks, I've looked a bit deeper than my one-line fix, based on your
> feedback.
> 
> Yes, we can remove badflag. be64_to_cpu() alone doesn't fix the
> trap, though, since it's a no-op on big-endian. gcc still reads
> hkey->rmap.rm_offset with the same 8-byte ldx. I tried it on my
> T4-1 and the fault count didn't change.
> 
> The other places get away with it because they go through a
> struct xfs_rmap_key pointer first (kp = &key->rmap in
> xfs_rmapbt_cmp_key_with_cur() and xfs_rmapbt_cmp_two_keys()), and since
> that struct is packed gcc uses byte loads.

Ah, that explains why those work without issue - that's the bit I
missed.

> I suggest we do the the same here, with be64_to_cpu() and no badflag.
> That gets the faults to zero on the T4-1. Can send that as a v2 later,
> if no one disagree with that approach.

It sounds like the right approach to me.

-Dave.
-- 
Dave Chinner
dgc@kernel.org