Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756757Ab3JNPXM (ORCPT ); Mon, 14 Oct 2013 11:23:12 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]:52235 "EHLO elasmtp-galgo.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756152Ab3JNPXK (ORCPT ); Mon, 14 Oct 2013 11:23:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Fubug4LavcZUGGQ2+OT39vsoqEgf+6m/dHQGl7kOToHzlMeSquc3L8FQOrdNeHGm; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; From: "Frank Filz" To: Cc: "'Jeff Layton'" , "'Scott Lovenberg'" , "'Jeremy Allison'" , "'Andreas Dilger'" , , "'Ganesha NFS List'" , , "'Linux Kernel Mailing List'" References: <1381494322-2426-1-git-send-email-jlayton@redhat.com> <20131011200756.GB22160@fieldses.org> <20131011192118.483e436f@tlielax.poochiereds.net> <20131011234923.GD8688@samba2> <20131011204244.72c2d672@corrin.poochiereds.net> <024101cec776$8f004130$ad00c390$@mindspring.com> In-Reply-To: Subject: RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks Date: Mon, 14 Oct 2013 08:23:03 -0700 Message-ID: <02a901cec8f1$47ce0280$d76a0780$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIaxc2XaXMwhFVmMgrl8lqeyFTt4AHYOUbiArnvCugBgxKMZgIPcxlDA0h1vzIB7gYOMAKlnvr9AscrUJuYxhYLAA== Content-Language: en-us X-ELNK-Trace: 136157f01908a8929c7f779228e2f6aeda0071232e20db4d7f202c27376cb8b76fe05b74c15aa30c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.236.153.111 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1750 Lines: 38 > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/