On Mon, Dec 23, 2024 at 11:30:47AM -0500, Liam R. Howlett wrote:
> * cel@xxxxxxxxxx <cel@xxxxxxxxxx> [241220 10:33]:
> > From: Chuck Lever <chuck.lever@xxxxxxxxxx>
> >
> > According to getdents(3), the d_off field in each returned directory
> > entry points to the next entry in the directory. The d_off field in
> > the last returned entry in the readdir buffer must contain a valid
> > offset value, but if it points to an actual directory entry, then
> > readdir/getdents can loop.
> >
> > This patch introduces a specific fixed offset value that is placed
> > in the d_off field of the last entry in a directory. Some user space
> > applications assume that the EOD offset value is larger than the
> > offsets of real directory entries, so the largest possible offset
> > value is reserved for this purpose. This new value is never
> > allocated by simple_offset_add().
> >
> > When ->iterate_dir() returns, getdents{64} inserts the ctx->pos
> > value into the d_off field of the last valid entry in the readdir
> > buffer. When it hits EOD, offset_readdir() sets ctx->pos to the EOD
> > offset value so the last entry is updated to point to the EOD marker.
> >
> > When trying to read the entry at the EOD offset, offset_readdir()
> > terminates immediately.
> >
> > It is worth noting that using a Maple tree for directory offset
> > value allocation does not guarantee a 63-bit range of values --
> > on platforms where "long" is a 32-bit type, the directory offset
> > value range is still 0..(2^31 - 1).
>
> I have a standing request to have 32-bit archs return 64-bit values. Is
Yes, an allocation mechanism for 64-bit values on 32-bit would be very
nice to have.
