Possible UDP deadlock/panic fix

[Robert Watson]

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