Trying to wrap my head around this change, but what's wrong with the current assumption if we instead only consider this path an error if retval == 0? We might over-allocate for buf, but we'd presumably fit more into one call.

I believe it's the file position that gets in the way. kern_getdirentries() has already advanced past the whole native batch before this loop runs, so returning a short result here would skip the entries left in buf.

I tried that on UFS and ZFS: with a 768-byte buffer, enumeration completes without an error, but 112 of the 1002 entries are missing. This change returns all 1002. We'd need to preserve the remainder or arrange to commit the position after the last returned entry to handle partial batches correctly. Rounding down avoids that for counts >= DEV_BSIZE, though you're right that it can return fewer entries per call.

Ah, ok, so the cause here being that linux_getdirentries will loop on kern_getdirentries calls. VOP_READDIR implementations at places like [0] would normally avoid an EINVAL because we wrote something out, but this is a subsequent call to kern_getdirentries() -- we wrote something out in a previous one, but not in this one. linux_getdirentries can't reallly distinguish between this and other EINVAL cases, so we don't have much option beyond undersizing without plumbing something else through kern_getdirentries().

Does that sound like an accurate assessment?

[0] https://cgit.freebsd.org/src/tree/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c#n1838

I added some tracing to understand this better. For the failing 768-byte request on UFS and ZFS, I see one successful kern_getdirentries() call producing 1000 native bytes, with no retry in linux_getdirentries(). EINVAL then comes from the conversion check: 720 Linux bytes have been copied, 48 remain in the caller’s buffer, and the next translated directory entry needs 96 bytes.

It looks like this reproducer is running out of space when converting into the Linux buffer, after the native read has completed. Could that be a different path from the retry case you had in mind?