hi,
> + status = nlmclnt_proc(inode, cmd, fl);
> + /* If we were signalled we still need to ensure that
> + * we clean up any state on the server. We therefore
> + * record the lock call as having succeeded in order to
> + * ensure that locks_remove_posix() cleans it out when
> + * the process exits.
> + */
> + if (status == -EINTR || status == -ERESTARTSYS)
> + posix_lock_file(filp, fl, 0);
> + unlock_kernel();
> + if (status < 0)
> + return status;
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.
YAMAMOTO Takashi
>
> 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
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
>> 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