Date: Fri, 15 Apr 2011 11:27:06 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, trasz@freebsd.org Subject: Re: svn commit: r220526 - head/sys/kern Message-ID: <20110415082706.GI48734@deviant.kiev.zoral.com.ua> In-Reply-To: <201104141713.28311.jhb@freebsd.org> References: <201104101707.p3AH736T054347@svn.freebsd.org> <201104141713.28311.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Thu, Apr 14, 2011 at 05:13:28PM -0400, John Baldwin wrote: > On Sunday, April 10, 2011 1:07:03 pm Konstantin Belousov wrote: > > Author: kib > > Date: Sun Apr 10 17:07:02 2011 > > New Revision: 220526 > > URL: http://svn.freebsd.org/changeset/base/220526 > > > > Log: > > Some callers of proc_reparent() already have the parent process locked. > > Detect the situation and avoid process lock recursion. > > > > Reported by: Fabian Keil <freebsd-listen fabiankeil de> > > > > Modified: > > head/sys/kern/kern_exit.c > > Can we instead assert it is always held and fix callers that don't? Using > locked variables is messy and I'd rather avoid it when possible. We already > require the caller to hold other locks for this operation. > I agree that this is ugly, and proper fix probably would be something else. E.g. struct proc could grow another field that holds a pointer to the ucred it is accounted for, and locked with some global lock. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2oAVoACgkQC3+MBN1Mb4ipJwCdGBm37JsjAiBc1EToMmI+b6Dp czgAoMIsuLe4E8WTDYf8pVNiMKUC87D5 =cQRQ -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110415082706.GI48734>