2011/4/15 Kostik Belousov <kostik...@gmail.com>: > On Fri, Apr 15, 2011 at 12:46:18PM -0400, Attilio Rao wrote: >> 2011/4/15 Kostik Belousov <kostik...@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.
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 -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
