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
Hi,
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.
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"
>
On September 22, 2008, Robert Watson wrote:> your confirmation as to whether or not this corrects the > specific symptoms you are seeing would be very helpful.14+ hours under load with the patch and all is well. Thanks! -- Norbert.