linux-kernel - RE: OFD ("file private") locks and NFS

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

Message-ID: <030601cf63bd$4c635220$e529f660$@mindspring.com>
Date:	Tue, 29 Apr 2014 08:11:27 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	"'Jeff Layton'" <jlayton@...chiereds.net>,
	"'Matt W. Benjamin'" <matt@...uxbox.com>
Cc:	"'Ganesha NFS List'" <nfs-ganesha-devel@...ts.sourceforge.net>,
	"'lkml'" <linux-kernel@...r.kernel.org>,
	"'Linux-Fsdevel'" <linux-fsdevel@...r.kernel.org>,
	"'Trond Myklebust'" <trond.myklebust@....uio.no>,
	"'J. Bruce Fields'" <bfields@...ldses.org>,
	"'Neil Brown'" <neilb@...e.de>, <samba-technical@...ts.samba.org>,
	<linux-nfs@...r.kernel.org>,
	"'Michael Kerrisk \(man-pages\)'" <mtk.manpages@...il.com>
Subject: RE: OFD ("file private") locks and NFS

> On Tue, 29 Apr 2014 07:40:08 -0400 (EDT) "Matt W. Benjamin"
> <matt@...uxbox.com> wrote:
> 
> > Hi Jeff,
> >
> > Something which came up on the last Ganesha conn call is that we have
> > a pretty strong need for some ability to wait on a set of locks, and
> > perhaps receive events.  Frank Filz believed that you had made a
> > proposal which would cover this.  Can you elaborate on that?
> >
> > Thanks,
> >
> > Matt
> >
> 
> No, there's no mechanism to wait on a set of locks from within the context
of
> a single thread of execution or to receive "events". Again, that would be
a
> new API beyond what I've been proposing over the last several months.

Some kind of facility to enable one user space thread to wait on multiple
blocked locks would definitely be helpful to user space servers.

Our current plan is to have a pool of threads, and dispatch blocking locks
to them. If that pool is exhausted, all further locks would be dispatched to
a single thread that would poll for locks.

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/