Re: corruption due to loss of lock

[Malahal Naineni <malahal@us.ibm.com>]

Jeff Layton [jlayton@redhat.com] wrote:
> On Thu, 13 Jun 2013 13:47:37 -0500
> Malahal Naineni <malahal@us.ibm.com> wrote:
> 
> > Hi Trond,
> > 
> > I saw Bryan's patches here https://patchwork.kernel.org/patch/987402/
> > that fix issues after loss of a lock.  What is the status on this patch
> > set? Do they need more work? We have an application that uses range
> > locks on a file. Two threads from two different clients end up writing
> > to the same a file due to this bug after a lease expiry from a client.
> > 
> > Regards, Malahal.
> 
> (cc'ing Bryan since he did the original set)
> 
> Yeah, this set would be a nice thing to have. A couple of comments:
> 
> - I still think it would be best to make SIGLOST its own signal, but as
>   Bryan points out, it would need to be larger than SIGRTMAX. I'm
>   not sure that's possible on all arches with the way the RT signals
>   were done. It's probably worth investigating that though before
>   settling on SIGIO since it would be hard to change that retroactively.

Our application doesn't handle SIGIO, so it was terminating due to
SIGIO. We tested without SIGIO/SIGLOST part of the patch, it stopped
sending writes to NFS server as expected but the application didn't
receive EIO because the original patch set some task fields and didn't
call rpc_exit(). I just had to modify nfs_write_prepare() to call
rpc_exit(task) rather than modifying task status and action fields
directly.

I will post my patch after some more testing.

> 
> - This is not really a v4.1 specific thing. It should also be done for
>   v4.0 and v2/3, though the latter two really need to be done within
>   lockd.

Correct.

Regards, Malahal.