linux-kernel - f_owner.lock and file->pos updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <f2b55d220703071117n474f02f7rcc630f0415530aed@mail.gmail.com>
Date:	Wed, 7 Mar 2007 11:17:36 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: f_owner.lock and file->pos updates

Suppose I want to create an atomic llseek+writev operation.  Is this
more or less sufficient:

    ssize_t ret = -EBADF;
    file = fget_light(fd, &fput_needed);
    if (file) {
            if (unlikely(origin > 2)) {
                    ret = -EINVAL;
            } else {
                    write_lock_irq(&file->f_owner.lock);
                    pos = vfs_llseek(file, ((loff_t) offset_high <<
32) | offset_low, origin);
                    ret = (ssize_t)pos;
                    if (likely(ret >= 0)) {
                            ret = vfs_writev(file, vec, vlen, &pos);
                            file_pos_write(file, pos);
                    }
                    write_unlock_irq(&file->f_owner.lock);
            }
            fput_light(file, fput_needed);
    }

Or is this the wrong sort of lock to be using to protect against
having file->pos altered by another thread executing through the same
code?

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/