Re: [PATCH 0/2] fs: honor FOP_UNSIGNED_OFFSET in llseek and positional I/O

[Stian Halseth]

Hi again, a small clarification to my last reply.

On Thu, 2026-09-17 at 18:45 +0200, Stian Halseth wrote:
> 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.
Just to clarify:
With patch 1, _llseek for ppc64 and sparc64 behaves just like lseek for
the other arches, correct for every offset outside of that top window.
> 
> Best regards,
> Stian
> 
> > 
> > Thanks,
> > Florian
> >

Attachment: signature.asc
Description: This is a digitally signed message part