From owner-svn-src-all@FreeBSD.ORG Fri Apr 15 17:01:18 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B227106564A; Fri, 15 Apr 2011 17:01:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3438FC16; Fri, 15 Apr 2011 17:01:16 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p3FH10e5047717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 20:01:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p3FH10Th002829; Fri, 15 Apr 2011 20:01:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p3FH10or002828; Fri, 15 Apr 2011 20:01:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Apr 2011 20:01:00 +0300 From: Kostik Belousov To: Attilio Rao Message-ID: <20110415170100.GM48734@deviant.kiev.zoral.com.ua> References: <201104101707.p3AH736T054347@svn.freebsd.org> <201104141713.28311.jhb@freebsd.org> <20110415082706.GI48734@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Rex5+51txc1ort/q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, trasz@freebsd.org, John Baldwin Subject: Re: svn commit: r220526 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:01:18 -0000 --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 : > > 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 > >> > > >> > 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--