svn commit: r220526 - head/sys/kern

[Kostik Belousov]

On Fri, Apr 15, 2011 at 12:46:18PM -0400, Attilio Rao wrote:
> 2011/4/15 Kostik Belousov <kostikbel at 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:
> >> >   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.
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110415/4dbe2f78/attachment.pgp