From owner-freebsd-bugs Thu Dec 17 14:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24966 for freebsd-bugs-outgoing; Thu, 17 Dec 1998 14:10:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24960 for ; Thu, 17 Dec 1998 14:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from Unknown UID 563@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA15605; Thu, 17 Dec 1998 14:10:00 -0800 (PST) Date: Thu, 17 Dec 1998 14:10:00 -0800 (PST) Message-Id: <199812172210.OAA15605@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Alfred Perlstein Subject: Re: kern/8732: nfs mounts with 'intr' can cause system hang Reply-To: Alfred Perlstein Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8732; it has been noted by GNATS. From: Alfred Perlstein To: "David G. Andersen" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/8732: nfs mounts with 'intr' can cause system hang Date: Thu, 17 Dec 1998 17:07:10 -0500 (EST) On Thu, 17 Dec 1998, David G. Andersen wrote: > Okay.. hrm. Want to try a different one? > > Index: vfs_subr.c > =================================================================== > RCS file: /n/marker/usr/lsrc/FreeBSD/CVS/src/sys/kern/vfs_subr.c,v > retrieving revision 1.174 > diff -r1.174 vfs_subr.c > 582,584c582,587 > < tsleep((caddr_t)&vp->v_numoutput, > < slpflag | (PRIBIO + 1), > < "vinvlbuf", slptimeo); > --- > > if (error = tsleep((caddr_t)&vp->v_numoutput, > > slpflag | (PRIBIO + 1), > > "vinvlbuf", slptimeo)) { > > splx(s); > > return (error); > > } > > > (Instead of just checking for EINTR, it returns on any error) > > I managed to replicate the crash you had with my first patch, but it > took a lot more pounding for some reason. I haven't managed to crash > with this one yet, but who knows. > > -Dave ok, A & B A) ok, what if tsleep returns ERESTART? will the kernel allow the process to exit the kernel call? or will it loop retrying the syscall, and not allowing the process to return to userland? unless you say yes, i'll be trying the patch tonight (unplugging the ethernet to simulate an interrupted mount, then sending a ^C) B) well, um, i think i just got it. Basically a ^C will make tsleep return EINTR which will allow the process back to userland, but perhaps a SIGIO or some other call will make tsleep give ERESTART which will restart the IO? is it A or B or ??? thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message