From owner-cvs-all@FreeBSD.ORG Fri Jun 11 01:30:35 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2AE716A4CE; Fri, 11 Jun 2004 01:30:35 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A580C43D58; Fri, 11 Jun 2004 01:30:35 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id AA72B5C82D; Thu, 10 Jun 2004 18:30:23 -0700 (PDT) Date: Thu, 10 Jun 2004 18:30:23 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20040611013023.GJ78955@elvis.mu.org> References: <200406102134.i5ALYcNr004704@repoman.freebsd.org> <20040611012513.GI78955@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040611012513.GI78955@elvis.mu.org> User-Agent: Mutt/1.4.2.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_usrreq.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 01:30:35 -0000 * Alfred Perlstein [040610 18:26] wrote: > * Robert Watson [040610 14:34] wrote: > > rwatson 2004-06-10 21:34:38 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern uipc_usrreq.c > > Log: > > Introduce a subsystem lock around UNIX domain sockets in order to protect > > global and allocated variables. This strategy is derived from work > > originally developed by BSDi for BSD/OS, and applied to FreeBSD by Sam > > Leffler: There's also a bug here in the locking I added for files/filedescs. On line 1525 nfiles is accessed without the filelist_lock held, so its value is inconsistant. A fix would be to peek at nfiles, do the allocation, then lock the filelist lock, then check the value to see if it changed if it changed to something lower, then free and re-malloc more memory. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684