From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 0/2] locks: allow mandatory locking to work with file-private locks Date: Mon, 10 Mar 2014 15:37:38 -0400 Message-ID: <20140310193738.GF28006@fieldses.org> References: <1394458607-23579-1-git-send-email-jlayton@redhat.com> <20140310192146.GE28006@fieldses.org> <20140310153129.04b084b8@ipyr.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, trond.myklebust@primarydata.com, Andy Lutomirski To: Jeffrey Layton Return-path: Received: from fieldses.org ([174.143.236.118]:60799 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753679AbaCJTho (ORCPT ); Mon, 10 Mar 2014 15:37:44 -0400 Content-Disposition: inline In-Reply-To: <20140310153129.04b084b8@ipyr.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Mar 10, 2014 at 03:31:29PM -0400, Jeffrey Layton wrote: > On Mon, 10 Mar 2014 15:21:46 -0400 > "J. Bruce Fields" wrote: > > > On Mon, Mar 10, 2014 at 09:36:45AM -0400, Jeff Layton wrote: > > > This patchset fixes the problems that Trond pointed out last week, > > > namely that you can end up deadlocking yourself if you set a > > > file-private lock on a file and then do some I/O on the same. > > > > > > With this set, mandatory locking should work more or less as you'd > > > expect with file-private locks. If you set a lock on an open file > > > and then do some I/O on it, it won't block. If you try to lock and > > > do I/O on different open files, then the I/O may end up blocked. > > > > > > Note that this approach is just as racy as the existing mandatory > > > lock implementation, but I don't think it makes anything worse > > > there. > > > > As another alternative, could we declare file-private locks to never > > be mandatory? > > > > The mandatory bit has only ever applied to traditional posix locks, > > so I don't think there's necessarily a presumption they'd apply to > > this new lock type as well. > > > > That doesn't necessarily simplify the locks_mandatory_area case as it > > then needs __posix_lock_file to be able to ignore traditional posix > > locks. > > > > Erm...I think you mean "ignore file-private locks"... Yep, sorry. (well, "optionally ignore file-private locks", with the option taken in locks_mandatory_area). > We certainly could do that, but I'm not sure I really like it any > better and it'd be harder to code that up. What would be the benefit of > doing that instead? I'd just rather limit the scope of mandatory locking where possible. It's not a big deal I guess. --b. > I'm not a real fan of mandatory locking but my aim all along has been > to allow fp locks to work as much like classic locks as possible. Is > there a compelling reason to make them different here? > > -- > Jeff Layton