MIME-Version: 1.0
In-Reply-To: <53F612DC.60006@redhat.com>
References: <1438879608.14503585.1407251825405.JavaMail.zimbra@redhat.com>
	<1408580933.4029.2.camel@leira.trondhjem.org>
	<53F612DC.60006@redhat.com>
Date: Thu, 21 Aug 2014 11:50:36 -0400
Message-ID: <CAHQdGtRw0V=mAuXs=UL7aJxxvKo26xqVoyOwR7r+9PrGPNmn_g@mail.gmail.com>
Subject: Re: [PATCH] nfs: Always try and release an NFS file lock, even after
 receiving a SIGKILL
From: Trond Myklebust <trond.myklebust@primarydata.com>
To: David Jeffery <djeffery@redhat.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-nfs-owner@vger.kernel.org

On Thu, Aug 21, 2014 at 11:40 AM, David Jeffery <djeffery@redhat.com> wrote:
> On 08/20/2014 08:28 PM, Trond Myklebust wrote:
>>
>> What guarantees that this does not lead to silent corruption of the file
>> if there are outstanding write requests?
>>
>
> Do you have a particular scenario in mind you are concerned about?
>
> Right before the code the patch modifies, nfs_sync_mapping() is called.
>  Any writes started before the unlock operation began have already been
> flushed, so we shouldn't have a corruption case of writes from before
> the unlock began being sent after the unlock is complete.
>
> Are you concerned about some other nfs4 writes being started while we
> initially waited on the counter?  Such a write racing with the unlock

No. I'm worried about the writes that have been started, but which are
now completing in the background while the lock is being freed.

> going ahead instead of erroring out could initially fail from a wrong
> state ID, but should retry with the new state.  Is there something I've
> overlooked?

Loss of lock atomicity due to the fact that the writes are completing
after the lock was released.

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

trond.myklebust@primarydata.com