From owner-cvs-all@FreeBSD.ORG Mon Feb 26 03:38:11 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6850416A400; Mon, 26 Feb 2007 03:38:11 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [69.147.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 595A413C428; Mon, 26 Feb 2007 03:38:11 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id l1Q3cBJB035093; Mon, 26 Feb 2007 03:38:11 GMT (envelope-from delphij@repoman.freebsd.org) Received: (from delphij@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id l1Q3cBCP035092; Mon, 26 Feb 2007 03:38:11 GMT (envelope-from delphij) Message-Id: <200702260338.l1Q3cBCP035092@repoman.freebsd.org> From: Xin LI Date: Mon, 26 Feb 2007 03:38:10 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/kern kern_fork.c kern_resource.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 03:38:11 -0000 delphij 2007-02-26 03:38:10 UTC FreeBSD src repository Modified files: sys/kern kern_fork.c kern_resource.c Log: Close race conditions between fork() and [sg]etpriority()'s PRIO_USER case, possibly also other places that deferences p_ucred. In the past, we insert a new process into the allproc list right after PID allocation, and release the allproc_lock sx. Because most content in new proc's structure is not yet initialized, this could lead to undefined result if we do not handle PRS_NEW with care. The problem with PRS_NEW state is that it does not provide fine grained information about how much initialization is done for a new process. By defination, after PRIO_USER setpriority(), all processes that belongs to given user should have their nice value set to the specified value. Therefore, if p_{start,end}copy section was done for a PRS_NEW process, we can not safely ignore it because p_nice is in this area. On the other hand, we should be careful on PRS_NEW processes because we do not allow non-root users to lower their nice values, and without a successful copy of the copy section, we can get stale values that is inherted from the uninitialized area of the process structure. This commit tries to close the race condition by grabbing proc mutex *before* we release allproc_lock xlock, and do copy as well as zero immediately after the allproc_lock xunlock. This guarantees that the new process would have its p_copy and p_zero sections, as well as user credential informaion initialized. In getpriority() case, instead of grabbing PROC_LOCK for a PRS_NEW process, we just skip the process in question, because it does not affect the final result of the call, as the p_nice value would be copied from its parent, and we will see it during allproc traverse. Other potential solutions are still under evaluation. Discussed with: davidxu, jhb, rwatson PR: kern/108071 MFC after: 2 weeks Revision Changes Path 1.267 +14 -5 src/sys/kern/kern_fork.c 1.167 +3 -0 src/sys/kern/kern_resource.c