Re: [PATCH 0/2] fs: honor FOP_UNSIGNED_OFFSET in llseek and positional I/O
From: Stian Halseth
Date: Thu Sep 17 2026 - 14:33:51 EST
Hi,
On Thu, 2026-09-17 at 18:01 +0200, Florian Weimer wrote:
> * Stian Halseth:
>
> > Tested on an UltraSPARC T4: pread(), preadv(), pwrite(), pwritev()
> > and
> > lseek() on /proc/PID/mem at positions above 2^63 return the correct
> > data
> > and offset; a negative position on a regular file or a pipe still
> > fails
> > with EINVAL and position 0 on a pipe with ESPIPE, as before; and
> > the
> > stock pldd(1) works again. On other architectures the change is a
> > no-op
> > for every file without FOP_UNSIGNED_OFFSET, and userspace addresses
> > never set the top bit, so the new paths are only reachable by
> > passing
> > a bogus position to /proc/PID/mem or /dev/mem, which then fails in
> > the
> > driver instead of the wrapper.
>
> For lseek, aren't some file offsets (the top 4095 bytes or so just
> before 2**64) ambiguous as error indicators? You would have to use
> _llseek when accessing /proc/PID/mem.
Yes, for lseek, anything in the top MAX_ERRNO bytes below 2^64 cannot
be separated from -errno.
For that reason _llseek is the interface that can be exact.
Patch 1 ensures that _llseek works for everything except that 4095-byte
window. The patch does _not_ change the fact that _llseek can't return
an offset in said window.
I think fixing the window requires llseek to report errors separately
from the offset. A bigger change, I would need some feedback before
attempting to implement that.
That being said, I _think_ the window is unreachable in practice, and
that no architecture maps user memory there.
I could add a sentense to patch 1 noting the limitation, or look at the
larger change if the VFS maintainers think it's worth it.
On the glibc side: 64-bit glibc uses lseek except on sparc64 and ppc64,
which use _llseek, so those two get the exact result with patch 1,
and the rest carry the lseek ambiguity for that top window regardless.
Best regards,
Stian
>
> Thanks,
> Florian
>
Attachment:
signature.asc
Description: This is a digitally signed message part