From owner-freebsd-stable@FreeBSD.ORG Tue May 24 17:36:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9500716A41C for ; Tue, 24 May 2005 17:36:49 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C61743D4C for ; Tue, 24 May 2005 17:36:48 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 May 2005 13:36:46 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id A8FF013647; Tue, 24 May 2005 13:36:48 -0400 (EDT) Date: Tue, 24 May 2005 13:36:48 -0400 From: Ed Maste To: freebsd-stable@freebsd.org Message-ID: <20050524173648.GA29183@sandvine.com> References: <20050524165907.GA20674@sandvine.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: <20050524165907.GA20674@sandvine.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 24 May 2005 17:36:46.0441 (UTC) FILETIME=[2863D590:01C56087] Subject: Re: libc_r kqueue fd leak 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: Tue, 24 May 2005 17:36:49 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote: > We discovered a kqueue leak when running one of our 4.x applications on > FreeBSD 5.3 using the compat libc_r. It turns out it's caused by libc_r's > close() failing. I've attached a patch which stops libc_r close() from bailing if fstat() returns an error. This fixes the kqueue leak. This logic would also have to make its way into the compat library via 4.x to fully resolve the issue. -- Ed Maste, Sandvine Incorporated --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uthread_close.c.patch" --- uthread_close.c.orig 2005-05-24 13:22:14.000000000 -0400 +++ uthread_close.c 2005-05-24 13:21:05.000000000 -0400 @@ -63,8 +63,7 @@ * Lock the file descriptor while the file is closed and get * the file descriptor status: */ - else if (((ret = _FD_LOCK(fd, FD_RDWR, NULL)) == 0) && - ((ret = __sys_fstat(fd, &sb)) == 0)) { + else if ((ret = _FD_LOCK(fd, FD_RDWR, NULL)) == 0) { /* * Check if the file should be left as blocking. * @@ -85,7 +84,8 @@ * using, which would then cause any reads to block * indefinitely. */ - if ((S_ISREG(sb.st_mode) || S_ISCHR(sb.st_mode)) + if (__sys_fstat(fd, &sb) == 0 && + (S_ISREG(sb.st_mode) || S_ISCHR(sb.st_mode)) && (_thread_fd_getflags(fd) & O_NONBLOCK) == 0) { /* Get the current flags: */ flags = __sys_fcntl(fd, F_GETFL, NULL); --qcHopEYAB45HaUaB--