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:	Mon, 14 Oct 2013 08:23:03 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	<Volker.Lendecke@...Net.DE>
Cc:	"'Jeff Layton'" <jlayton@...hat.com>,
	"'Scott Lovenberg'" <scott.lovenberg@...il.com>,
	"'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

> 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...
> 
> Yes, please :-)

What model would be useful to you (and for what project)? One thing I could
think of is since we have a file descriptor for each lock owner/file pair,
we could do something like select on those descriptors, got to think about
how that would actually work though... The vfs lock layer does inherently
support a kernel call back when a blocked lock can be unblocked, so we just
need to figure out the best way to hook that up to user space in a way that
doesn't require a thread per blocked 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/