From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH] AFS: Implement file locking Date: Tue, 29 May 2007 10:34:41 +0100 Message-ID: <28654.1180431281@redhat.com> References: <20070527161252.GA12804@fieldses.org> <20070527022502.GB10867@fieldses.org> <20070526022342.GA20905@fieldses.org> <20070524165554.22292.38887.stgit@warthog.cambridge.redhat.com> <7436.1180223730@redhat.com> <18750.1180255870@redhat.com> Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: "J. Bruce Fields" Return-path: Received: from mx1.redhat.com ([66.187.233.31]:52130 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbXE2Jeu (ORCPT ); Tue, 29 May 2007 05:34:50 -0400 In-Reply-To: <20070527161252.GA12804@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org J. Bruce Fields wrote: > You can contrive examples of applications that would be correct given > the standard fcntl behavior, but that would deadlock on a system that > didn't allow read locks to jump the queue in the above situation. Yes, but you can also contrive starvation if you allow locks to jump the queue. Obviously, the Linux kernel behaviour is to allow readlocks to jump the queue if a readlock is currently in force, so I have to conform to that, whether I like it or not. I'll need to test the upgrade/downgrade case. I don't know whether the AFS server supports that. If it doesn't, I can emulate downgrade, but not upgrade - not unless I only ever ask it for exclusive locks. Lock upgrading is really, really easy to contrive deadlock for. David