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

[David Timber]

On 3/22/26 20:52, David Timber wrote:
>> 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.
>> 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.
On the second thought, one possible scenario where the offsets to hole
and data being the same would be a TOCTOU condition where a hole has
been dug in between lseek() calls. Either way, that means the file is
being manipulated by multiple processes so in fallocate's case, it might
as well just terminate prematurely to be on the safe side.

btw, I don't maintain util-linux, so I'd just like to mention that it's
up to the maintainers to decide. In addition to that, other sparse-aware
userspace tools like compression filter, tar, and rsync always lstat()
before doing anything "sparse". The kernel returning EINVAL is more for
extereme edge cases like fallocate(to prevent such programs from
shooting themselves in the foot).
>> 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.
I just removed the confusing comments and made the function use one
return statement. We could do other errnos as per POSIX spec, but to be
honest, EINVAL should suffice. I get the gist of where you were getting
at - /dev/null isn't really the scope of POSIX so technically Linux
could do whatever.

I wouldn't complicate things. It's a simple dev node. So keep the code
simple?

Davo