Re: [PATCH 2/2] ocfs2: fix readdir position truncation on 32-bit kernels

[Andrew Morton]

On Thu,  6 Aug 2026 10:20:44 +0800 Zhan Xusheng <zhanxusheng1024@xxxxxxxxx> wrote:

> In ocfs2_dir_foreach_blk_el(), the directory cookie position is
> rebuilt with
> 
> 	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
> 
> `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
> unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask
> 
> 	~(sb->s_blocksize - 1)
> 
> is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
> block size).  In the AND expression with the 64-bit `ctx->pos`, that
> unsigned operand is zero-extended to 64 bits per the usual arithmetic
> conversions, yielding 0x00000000fffff000.  The high 32 bits of
> `ctx->pos` are silently cleared, even though directory size is
> allowed to exceed 4 GiB.
> 
> When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
> position is reset back into the first 4 GiB block, making the
> re-validation path re-enumerate already-returned dirents indefinitely.
> 
> This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
> for all non-inline directories, so a directory large enough to cross
> 4 GiB reaches it.
> 
> This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
> bitwise operation having different size") fixed in exfat, and the
> fix mirrors the equivalent ext4 fix in this series.  Cast the operand
> to loff_t so the mask is 64-bit before the AND:
> 
> 	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
> 
> 64-bit kernels are unaffected.

AI review had no comment on your change, but it might have found a
bunch of unrelated ocfs2 issues:

	https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xxxxxxxxxx