Re: [NFS] Re: [NFS client] NFS locks not released on abnormal process termination

Re: [NFS] Re: [NFS client] NFS locks not released on abnormal process termination

[Philippe Troin]

"Chris Croswhite" <csc@cadence.com> writes:

> Philippe,
> 
> What patches are you refering to?

The one in <87llpms8yr.fsf@ceramic.fifi.org> named
linux-2.4.23-nfs-lock-race-2.patch 

Here a link to MARC, since the sourceforge mailing list web page
sucks:

  http://marc.theaimsgroup.com/?l=linux-nfs&m=107095817723325&w=2

Phil.

> -----Original Message-----
> From:	Philippe Troin [mailto:phil@fifi.org]
> Sent:	Tue 09-Dec-03 10:46
> To:	Trond Myklebust
> Cc:	Kenny Simpson; linux-kernel@vger.kernel.org; nfs@lists.sourceforge.net
> Subject:	[NFS] Re: [NFS client] NFS locks not released on abnormal process termination
> Trond Myklebust <trond.myklebust@fys.uio.no> writes:
> 
> > >>>>> " " == Philippe Troin <phil@fifi.org> writes:
> > 
> >      > From my reading of the patch, it supersedes the old patch, and
> >      > is only
> >      > necessary on the client. Is also does not compile :-)
> > 
> > Yeah, I admit I didn't test it out...
> > 
> >      > Here's an updated patch which does compile.
> > 
> > Thanks.
> > 
> >      > I am still running tests, but so far it looks good (that is all
> >      > locks are freed when a process with locks running on a NFS
> >      > client is killed).
> > 
> > Good...
> 
> I've ran test overnight on four boxen, and no locks were lost.
> I guess you can send this patch to Marcello now.
> 
> I've tested with the enclosed program.
> 
>  
> > There are still 2 other issues with the generic POSIX locking code.
> > Both issues have to do with CLONE_VM and have been raised on
> > linux-kernel & linux-fsdevel. Unfortunately they met with no response,
> > so I'm unable to pursue...
> 
> Can we help? Pointers?
> 
> Phil.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs

Re: [NFS client] NFS locks not released on abnormal process termination

[trond.myklebust]

>
> i think it's problematic because you can't assume the lock was
> granted on the server and the signaled process might not exit
> immediately.

The point is that it is *worse* to assume the lock was not granted,
since then it will never get cleared on the server.

The RPC layer blocks all signals except SIGKILL, so the signalled
process has no choice but to exit immediately if something gets
through.

Cheers,
  Trond

Re: [NFS] Re: [NFS client] NFS locks not released on abnormal process termination

[YAMAMOTO Takashi]

hi,

> > i think it's problematic because you can't assume the lock was
> > granted on the server and the signaled process might not exit
> > immediately.
> 
> The point is that it is *worse* to assume the lock was not granted,
> since then it will never get cleared on the server.

yes.

> The RPC layer blocks all signals except SIGKILL, so the signalled
> process has no choice but to exit immediately if something gets
> through.

we're talking about interruptible mounts, aren't we?

are you referring to rpc_clnt_sigmask() ?
i think it isn't safe to assume sa_handler isn't changed during
blocking for lock.  consider CLONE_SIGHAND, for example.

YAMAMOTO Takashi

Re: [NFS] Re: [NFS client] NFS locks not released on abnormal process termination

[trond.myklebust]

>> The RPC layer blocks all signals except SIGKILL, so the signalled
>> process has no choice but to exit immediately if something gets
>> through.
>
> we're talking about interruptible mounts, aren't we?
>
> are you referring to rpc_clnt_sigmask() ?
> i think it isn't safe to assume sa_handler isn't changed during
> blocking for lock.  consider CLONE_SIGHAND, for example.

So what? If you decide handle a signal, then you are taking full
responsibility for the recovery process. It is up to _you_ to take action
to either recover the lock or to undo it, not the kernel. To determine
whether or not the lock was taken on the server you can just do a
fcntl(GETLK) call.

All the kernel cares about is that when the process exits, it needs to
clean up all the locks that are owned by that pid.

Cheers,
  Trond