Re: [PATCH] libfs: fix accidental overflow in offset calculation

[Al Viro <viro@zeniv.linux.org.uk>]

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.