On Fri, May 10, 2024 at 07:33:12AM +0100, Al Viro wrote:
> As the matter of fact, it would be interesting to find out
> which instances, if any, do *not* have that relationship
> between SEEK_CUR and SEEK_SET. If such are rare, it might
> make sense to mark them as such in file_operations and
> have vfs_llseek() check that - it would've killed a whole
> lot of boilerplate. And there it a careful handling of
> overflow checks (or a clear comment explaining what's
> going on) would make a lot more sense.
>
> IF we know that an instance deals with SEEK_CUR as SEEK_SET to
> offset + ->f_pos, we can translate SEEK_CUR into SEEK_SET
> in the caller.
FWIW, weird instances do exist.
kernel/printk/printk.c:devkmsg_llseek(), for example. Or this
gem in drivers/fsi/i2cr-scom.c:
static loff_t i2cr_scom_llseek(struct file *file, loff_t offset, int whence)
{
switch (whence) {
case SEEK_CUR:
break;
case SEEK_SET:
file->f_pos = offset;
break;
default:
return -EINVAL;
}
return offset;
}
SEEK_CUR handling in particular is just plain bogus: lseek(fd, -9, SEEK_CUR)
doing nothing to current position and returning EBADF. Even if you've done
lseek(fd, 9, SEEK_SET) just before that...
I suspect that some of those might be outright bugs; /dev/kmsg one probably
isn't, but by the look of it those should be rare.
Then there's orangefs_dir_llseek(), with strange handling of SEEK_SET
(but not SEEK_CUR); might or might not be a bug...
>From the quick look it does appear that it might be a project worth
attempting - exceptions are very rare.
