Date: Fri, 15 Apr 2011 20:01:00 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, trasz@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r220526 - head/sys/kern Message-ID: <20110415170100.GM48734@deviant.kiev.zoral.com.ua> In-Reply-To: <BANLkTimCUKTnkNMtbgpi%2Bt6%2BfyYPKc5uEw@mail.gmail.com> References: <201104101707.p3AH736T054347@svn.freebsd.org> <201104141713.28311.jhb@freebsd.org> <20110415082706.GI48734@deviant.kiev.zoral.com.ua> <BANLkTimCUKTnkNMtbgpi%2Bt6%2BfyYPKc5uEw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Rex5+51txc1ort/q Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2011 at 12:46:18PM -0400, Attilio Rao wrote: > 2011/4/15 Kostik Belousov <kostikbel@gmail.com>: > > 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: > >> > =9A Some callers of proc_reparent() already have the parent process = locked. > >> > =9A Detect the situation and avoid process lock recursion. > >> > > >> > =9A Reported by: =9A =9A =9AFabian Keil <freebsd-listen fabiankeil d= e> > >> > > >> > Modified: > >> > =9A head/sys/kern/kern_exit.c > >> > >> Can we instead assert it is always held and fix callers that don't? = =9AUsing > >> locked variables is messy and I'd rather avoid it when possible. =9AWe= already > >> require the caller to hold other locks for this operation. > >> > > I agree that this is ugly, and proper fix probably would be something e= lse. > > E.g. struct proc could grow another field that holds a pointer to the u= cred > > it is accounted for, and locked with some global lock. >=20 > As you already hold allproc_lock the process can't be distructed, then > as I already pointed out to Tomasz, it should alright to just bump the > refcount for cred and pass down, I guess. I do not see how allproc_lock is useful there, unless setuid(2) and other syscalls, which change the process credentials, are protected by the same lock. The issue there is in accounting for wrong container. You want to avoid a race between dereferencing stale p_ucred and the process moving to another container. --Rex5+51txc1ort/q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2oecsACgkQC3+MBN1Mb4i1XwCeIF9qTEUMAeJyleMI/x9FvmIs QmAAn08YXHnxCUvQmb/rb/0oZn5oMZap =omN2 -----END PGP SIGNATURE----- --Rex5+51txc1ort/q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110415170100.GM48734>