linux-kernel - Re: [PATCH] locks: Ability to test for flock presence on fd

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 10 Sep 2014 09:32:32 -0400
From:	Jeff Layton <jlayton@...chiereds.net>
To:	Pavel Emelyanov <xemul@...allels.com>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH] locks: Ability to test for flock presence on fd

On Tue, 9 Sep 2014 12:18:21 -0400
"J. Bruce Fields" <bfields@...ldses.org> wrote:

> On Tue, Sep 02, 2014 at 11:07:14PM +0400, Pavel Emelyanov wrote:
> > > Would it make sense to return the lock type held instead, so you could
> > > do one flock(fd, LOCK_TEST) instead of flock(fd, LOCK_TEST|LOCK_SH) and
> > > flock(fd, LOCK_TEST|LOCK_EX) ?
> > 
> > Well, in our case we parse /proc/locks anyway to see what
> > files at least to test for being locked. But what you propose
> > looks even better. I'll look what can be done here.
> 
> Actually I think I prefer your version.  It seems cleaner to define
> LOCK_TEST as returning the same result as you'd get if you actually
> tried the lock, just without applying the lock.  It avoids having a
> different return-value convention for this one command.  It might avoid
> some ambiguity in cases where the flock might be denied for reasons
> other than a conflicting flock (e.g. on NFS where flocks and fcntl locks
> conflict).  It's closer to what GETLK does in the fcntl case.
> 

Yeah, I think I agree here too. Best to keep the interface as simple
as possible, and the principle of least surprise would dictate that the
return value match how other flock() calls work.

I would still like to see a proposed manpage update for it. For bonus
points, writing a section on flock() for the glibc manual might help
get that piece merged as well.

It was my experience that getting the small header file #defines into
glibc for OFD locks was much more difficult than the kernel piece. YMMV
of course, but getting the glibc folks to buy into the idea ahead of
time would be good if possible.

-- 
Jeff Layton <jlayton@...chiereds.net>
--
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/