Date: Tue, 23 Sep 2008 22:37:21 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Mario Sergio Fujikawa Ferreira <lioux-list@uol.com.br> Cc: Norbert Papke <fbsd-ml@scrapper.ca>, stable@FreeBSD.org Subject: Re: Possible UDP deadlock/panic fix Message-ID: <alpine.BSF.1.10.0809232236410.68287@fledge.watson.org> In-Reply-To: <48D8BF69.6060206@uol.com.br> References: <alpine.BSF.1.10.0809220937320.58772@fledge.watson.org> (sfid-20080922_05543_31152F2E) <48D8BF69.6060206@uol.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: > That seems to be working. I've been up and running for 7 hours now with > your patch. > > The machine is a bit slow but I have both WITNESS and INVARIANTS enabled > so as to make sure everything is fine. I've now merged the fix to stable/7, thanks to both of you for reporting the problem. Robert N M Watson Computer Laboratory University of Cambridge > > Rergads, > Mario > > Robert Watson wrote: >> >> Attached is an MFC candidate for a patch I just merged to 8.x, which >> corrects the UDP lock recursion issue both of you were running into. If it >> settles well for a couple of days in HEAD then I'll go ahead and request an >> MFC from re@, but your confirmation as to whether or not this corrects the >> specific symptoms you are seeing would be very helpful. I was able to >> confirm that it eliminated what appeared to be the same problem here when I >> attempted to reproduce it based on the information you provided, so I'm >> hopeful.\ >> >> Thanks, >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >> >> Property changes on: . >> ___________________________________________________________________ >> Modified: svn:mergeinfo >> Merged /head/sys:r183265 >> >> Index: netinet6/udp6_usrreq.c >> =================================================================== >> --- netinet6/udp6_usrreq.c (revision 183265) >> +++ netinet6/udp6_usrreq.c (working copy) >> @@ -975,13 +975,23 @@ >> error = EINVAL; >> goto out; >> } >> + >> + /* >> + * XXXRW: We release UDP-layer locks before calling >> + * udp_send() in order to avoid recursion. However, >> + * this does mean there is a short window where inp's >> + * fields are unstable. Could this lead to a >> + * potential race in which the factors causing us to >> + * select the UDPv4 output routine are invalidated? >> + */ >> + INP_WUNLOCK(inp); >> + INP_INFO_WUNLOCK(&udbinfo); >> if (sin6) >> in6_sin6_2_sin_in_sock(addr); >> pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; >> - error = ((*pru->pru_send)(so, flags, m, addr, control, >> + /* addr will just be freed in sendit(). */ >> + return ((*pru->pru_send)(so, flags, m, addr, control, >> td)); >> - /* addr will just be freed in sendit(). */ >> - goto out; >> } >> } >> #endif >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0809232236410.68287>