Date: Thu, 10 Jun 2004 18:25:13 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_usrreq.c Message-ID: <20040611012513.GI78955@elvis.mu.org> In-Reply-To: <200406102134.i5ALYcNr004704@repoman.freebsd.org> References: <200406102134.i5ALYcNr004704@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Watson <rwatson@FreeBSD.org> [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: > > - Use of an sx lock for the file list mutex may cause problems with regard > to unp_mtx when garbage collection passed file descriptors. That is true, but I don't think there is a reason to hold the UNP lock inside of unp_gc except to protect the unp_gcing variable and when calling into unp_scan. You might be able to gloss over all of it by just using an sx lock instead of a mutex for the UNP lock. > - The locking in unp_pcblist() for sysctl monitoring is correct subject to > the unpcb zone not returning memory for reuse by other subsystems > (consistent with similar existing concerns). > > - Sam's version of this change, as with the BSD/OS version, made use of > both a global lock and per-unpcb locks. However, in practice, the > global lock covered all accesses, so I have simplified out the unpcb > locks in the interest of getting this merged faster (reducing the > overhead but not sacrificing granularity in most cases). We will want > to explore possibilities for improving lock granularity in this code in > the future. I noticed this in the BSD/os version, it was sort of like... "the global lock covers everything, what's the point of the underlying locks..?" Anyhow, good work, but the unp_gc stuff is surely going to bite us and needs to be fixed. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040611012513.GI78955>