On Wednesday June 18, jlayton@xxxxxxxxxx wrote:
>
> No objection to the patch, but what signal was being sent to nfsd when
> you saw this? If it's anything but a SIGKILL, then I wonder if we have
> a race that we need to deal with. My understanding is that we have nfsd
> flip between 2 sigmasks to prevent anything but a SIGKILL from being
> delivered while we're handling the local filesystem operation.
SuSE /etc/init.d/nfsserver does
killproc -n -KILL nfsd
so it looks like a SIGKILL.
>
> From nfsd():
>
> ----------[snip]-----------
> sigprocmask(SIG_SETMASK, &shutdown_mask, NULL);
>
> /*
> * Find a socket with data available and call its
> * recvfrom routine.
> */
> while ((err = svc_recv(rqstp, 60*60*HZ)) == -EAGAIN)
> ;
> if (err < 0)
> break;
> update_thread_usage(atomic_read(&nfsd_busy));
> atomic_inc(&nfsd_busy);
>
> /* Lock the export hash tables for reading. */
> exp_readlock();
>
> /* Process request with signals blocked. */
> sigprocmask(SIG_SETMASK, &allowed_mask, NULL);
>
> svc_process(rqstp);
>
> ----------[snip]-----------
>
> What happens if this catches a SIGINT after the err<0 check, but before
> the mask is set to allowed_mask? Does svc_process() then get called with
> a signal pending?
Yes, I suspect it does.
I wonder why we have all this mucking about this signal masks anyway.
Anyone have any ideas about what it actually achieves?
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
