From owner-cvs-src@FreeBSD.ORG Sat Aug 14 03:43:49 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAF3D16A4CE; Sat, 14 Aug 2004 03:43:49 +0000 (GMT) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB0143D3F; Sat, 14 Aug 2004 03:43:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.11/8.12.11) with ESMTP id i7E3hnfF017906; Sat, 14 Aug 2004 03:43:49 GMT (envelope-from rwatson@repoman.freebsd.org) Received: (from rwatson@localhost) by repoman.freebsd.org (8.12.11/8.12.11/Submit) id i7E3hndj017905; Sat, 14 Aug 2004 03:43:49 GMT (envelope-from rwatson) Message-Id: <200408140343.i7E3hndj017905@repoman.freebsd.org> From: Robert Watson Date: Sat, 14 Aug 2004 03:43:49 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sys/kern uipc_usrreq.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2004 03:43:49 -0000 rwatson 2004-08-14 03:43:49 UTC FreeBSD src repository Modified files: sys/kern uipc_usrreq.c Log: After completing a name lookup for a target UNIX domain socket to connect to, re-check that the local UNIX domain socket hasn't been closed while we slept, and if so, return EINVAL. This affects the system running both with and without Giant over the network stack, and recent ULE changes appear to cause it to trigger more frequently than previously under load. While here, improve catching of possibly closed UNIX domain sockets in one or two additional circumstances. I have a much larger set of related changes in Perforce, but they require more testing before they can be merged. One debugging printf is left in place to indicate when such a race takes place: this is typically triggered by a buggy application that simultaenously connect()'s and close()'s a UNIX domain socket file descriptor. I'll remove this at some point in the future, but am interested in seeing how frequently this is reported. In the case of Martin's reported problem, it appears to be a result of a non-thread safe syslog() implementation in the C library, which does not synchronize access to its logging file descriptor. Reported by: mbr Revision Changes Path 1.136 +18 -5 src/sys/kern/uipc_usrreq.c