Date: Thu, 25 Aug 2011 18:43:12 -0700 From: Artem Belevich <art@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-net@freebsd.org, Martin Birgmeier <la5lbtyi@aon.at> Subject: Re: amd + NFS reconnect = ICMP storm + unkillable process. Message-ID: <CAFqOu6huO2gOs-3b1zvYkFb6RVFiRhLPDA-=4OA4-Hxt5FpHjw@mail.gmail.com> In-Reply-To: <1499650185.371230.1314321868068.JavaMail.root@erie.cs.uoguelph.ca> References: <CAFqOu6hWry%2B_wkx8MJ7ept7v2o0EWBsiwu=%2BSHLJOVH69ToanA@mail.gmail.com> <1499650185.371230.1314321868068.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 25, 2011 at 6:24 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Btw, I fixed exactly the same issue for the TCP code (clnt_vc.c) in > r221127, so I wouldn't be surprised if the UDP code suffers the same The code in clnt_vc.c was exactly what made me wonder about treatment of ERESTART. > problem. I'll take a look at your patch tomorrow. You could also try > a TCP mount and see if the problem goes away. (For TCP on a pre-r221127 > system, the symptom would be a client thread looping in the kernel in > "R" state.) In my case the process was also stuck in unkillable running state because the process never returns from the syscall. Unfortunately amd itself seems to handle NFS requests for its own top-level mountpoints only via UDP. At least I haven't found a way to do so without hacking rather convoluted amd code. > I'll look tomorrow, but it sounds like you've figured it out. Looks like > a good catch to me at this point, rick Let me know if you're OK with the patch and I'll commit to head and MFC it to stable/8. --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6huO2gOs-3b1zvYkFb6RVFiRhLPDA-=4OA4-Hxt5FpHjw>