Re: [PATCH] drivers/char/mem.c: fix null and zero dev lseek

[David Timber]

(resending due to mail format error)

On 3/20/26 15:02, Greg KH wrote:
> On Fri, Mar 20, 2026 at 01:17:22PM +0900, David Timber wrote:
>> lseek() on /dev/null and /dev/zero always returns 0. This is
>> problematic for userland programs that detect holes and advancing
>> the offset by the delta (SEEK_HOLE - SEEK_DATA), which will always be
>> calculated as zero.
> But it's always worked this way, what changed to require this to now
> change?
No, it has not. This time, it's Linux who's at fault. For any other
whence the fs does not understand, it should return EINVAL. We can all
agree that this is bad because prooly written userspace code could go
unnoticed just because it's tested against /dev/null.
> What userspace tools are you going to break by doing this?
It will break poorly written userspace tools that call lseek() with a
wrong value or corrupted stack. I cannot give you the exact data, but in
my opinion, there's none. Yes, we don't break userspace, but in this
case, there wouldn't be any userspace to break.
> Where does POSIX require this to happen for these device nodes?
It is inferred from the fact that the offsets to SEEK_DATA and SEEK_HOLE
cannot be the same. Ever. This is why whence needs to be checked,
regardless of how the particular special device node or VFS behaves.

I don't know about the other device node types, but /dev/null is a
special case because its common use case is symlinking to mask regular
files. Say there's a unsuspecting script or userspace program that
applies the logic of dig_holes() without doing lstat() or [ -f "$FILE"
]. The userspace open()'s the path, the dereferenced path happens to be
/dev/null. The poor userspace steps into the loop and loops indefinitely.
> You just changed how userspace reacts to this, are you SURE that is
> going to be ok?
As far as I'm concerned, yes /I/ am sure. As outlined above, the start
of a hole and data cannot be the same.

I've check the behaviour of /dev/null on BSD's(the descendants of the
386BSD codebase) and Unices. All of the ones I've checked checks the
validity of whence(i.e. EINVAL is returned). It is in my opinion that
Linux fix this incorrect behaviour before SEEK_DATA and SEEK_HOLE(made
POSIX in 2024 spec) become widespread and the userspace implementations
depending on this broken behaviour start to appear.

At the end of the day, even if Linux decides to remain as that black
sheep, userspace can always cater to the peculiar of Linux as always.
Your call.
> And if you really want to do this, shouldn't you
> explicitly list what options you are going to return an error for, not
> the other way around in this switch statement?
Sure. See rerolled.

Davo