From owner-svn-src-all@FreeBSD.ORG Fri Apr 15 17:04:46 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 9E846106566C; Fri, 15 Apr 2011 17:04:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 057018FC1C; Fri, 15 Apr 2011 17:04:45 +0000 (UTC) Received: by gyg13 with SMTP id 13so1116784gyg.13 for ; Fri, 15 Apr 2011 10:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NIU3a0SKQnG49poaHTACeGRhEChv8KPa3K8K2HRUNp4=; b=SjhxQLlQdLdCUWSJhopSi7XdVAopFmB+zLpkTNO6w8YrivUoO5g1uMP4ZLsZnfXLdr Bu9iGm2H8biKYFKl1xzX3hwaq0CWys5m+hL1H2J6dqdfaIBVnHFy9z71EI1yLxMP74BO ZsjdAWyq2FvJluM4CgrHfH4xCF9gLaIrEgrFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=korpGo3FD/nwRxoGYc7c1TdNwdDsohqhnf271lVtwEH7Bcn/UZw572Jcibxu4Pe/+P fV/4Q4Jb9pL83smiSz2Xotgyrb0tbs58n3K955a2nyk38Ulgy+uN3KPIBaUKy75qXXDv wFtJryWiSXjZlhL89BicG2f+3lNBhUMAPmGJ8= MIME-Version: 1.0 Received: by 10.236.190.225 with SMTP id e61mr973975yhn.208.1302887085154; Fri, 15 Apr 2011 10:04:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.103.34 with HTTP; Fri, 15 Apr 2011 10:04:45 -0700 (PDT) In-Reply-To: <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> <20110415170100.GM48734@deviant.kiev.zoral.com.ua> Date: Fri, 15 Apr 2011 13:04:45 -0400 X-Google-Sender-Auth: U915dx_IORwXIUTRiX-ce4TLDUM Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:04:46 -0000 2011/4/15 Kostik Belousov : > 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: >> >> > =C2=A0 Some callers of proc_reparent() already have the parent proc= ess locked. >> >> > =C2=A0 Detect the situation and avoid process lock recursion. >> >> > >> >> > =C2=A0 Reported by: =C2=A0 =C2=A0 =C2=A0Fabian Keil >> >> > >> >> > Modified: >> >> > =C2=A0 head/sys/kern/kern_exit.c >> >> >> >> Can we instead assert it is always held and fix callers that don't? = =C2=A0Using >> >> locked variables is messy and I'd rather avoid it when possible. =C2= =A0We 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. >> >> 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. I thought the issue was just prevent destroying of process/ucred I may need to better look at callers then if you also want to avoid credentials changes. BTW, a global lock for that is not what I really hope to see. Attilio --=20 Peace can only be achieved by understanding - A. Einstein