Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Apr 2011 13:04:45 -0400
From:      Attilio Rao <attilio@freebsd.org>
To:        Kostik Belousov <kostikbel@gmail.com>
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:  <BANLkTimc20XgzHGWbEzjqAteOnSrN3VeJQ@mail.gmail.com>
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> <BANLkTimCUKTnkNMtbgpi%2Bt6%2BfyYPKc5uEw@mail.gmail.com> <20110415170100.GM48734@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/4/15 Kostik Belousov <kostikbel@gmail.com>:
> 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:
>> >> > =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 <freebsd-listen=
 fabiankeil de>
>> >> >
>> >> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimc20XgzHGWbEzjqAteOnSrN3VeJQ>