linux-kernel - RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Oct 2013 11:12:03 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	"'Jeff Layton'" <jlayton@...hat.com>,
	"'Scott Lovenberg'" <scott.lovenberg@...il.com>
Cc:	"'Jeremy Allison'" <jra@...ba.org>,
	"'Andreas Dilger'" <adilger@...ger.ca>,
	<linux-fsdevel@...r.kernel.org>,
	"'Ganesha NFS List'" <nfs-ganesha-devel@...ts.sourceforge.net>,
	<samba-technical@...ts.samba.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> This blog post of Jeremy's explains some of the history:
> 
> 
> http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2
> .html
> 
> See the section entitled "First Implementation Past the Post".

Interesting that Jeremy actually suggested the implementation should have
had an arbitrary lock owner as part of the flock structure:

"This is an example of a POSIX interface not being future-proofed against
modern techniques such as threading. A simple amendment to the original
primitive allowing a user-defined "locking context" (like a process id) to
be entered in the struct flock structure used to define the lock would have
fixed this problem, along with extra flags allowing the number of locks per
context to be recorded if needed."

But I'm happy with the lock context per kernel struct file as a solution,
especially since that will allow locks to be sensibly passed to a forked
process.

Another next step would be an asynchronous blocking lock...

Frank

--
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/