Re: rpc.mountd stops functioning

[Garrick Staples <garrick@usc.edu>]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Fri, Aug 27, 2004 at 07:16:54PM -0400, J. Bruce Fields alleged:
> On Fri, Aug 27, 2004 at 01:31:20PM +1000, Neil Brown wrote:
> > I don't think this patch is needed (though it wouldn't actually break anything).
> > The loop in svc_run.c starts:
> > 
> > 
> > 		readfds = svc_fdset;
> > 		cache_set_fds(&readfds);
> > 
> > so readfds is completely initialised at the top of the loop, so
> > clearing something at the bottom (which is essentially what this patch
> > does) should be a no-op.
> > 
> > Am I wrong?
> 
> Note that cache_process_req() (which the patch below modifies) is not
> all the way at the bottom of the loop; there's still an importan call to
> svc_getreqset() after it.
> 
> If I understand the problem correctly, what happens is that if select()
> returns with a set that includes two file descriptors, the first for a
> cache channel and the second for an rpc socket, and if we don't clear
> the first file descriptor from that set before passing it to
> svc_getreqset(), then the rpc code will try to read an rpc request from
> a cache channel file, and will get very confused.
> 
> The symptom is that mountd may die occasionally on a server that's
> using the new interface (hence mountd is handling upcalls), and that's
> getting a lot of mount requests.

Yes, this is exactly what happens.  The RPC code reading from the cache channel
file segfaults mountd every time.

On my two main fileservers, mountd would die every few hours.  Sometimes,
conditions being optimal to trigger the bug, it would chain-crash.  It hasn't
segfaulted at all since that one line patch.

I'm surprised more people haven't reported this segfault.  I guess not many
people are using the new interface in heavy production.

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]