From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 08:40:07 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAB26106564A; Mon, 22 Sep 2008 08:40:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A8B378FC0C; Mon, 22 Sep 2008 08:40:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 42AD646B2A; Mon, 22 Sep 2008 04:40:07 -0400 (EDT) Date: Mon, 22 Sep 2008 09:40:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Norbert Papke , lioux@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Possible UDP deadlock/panic fix X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 08:40:07 -0000 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