From owner-cvs-src@FreeBSD.ORG Mon Jul 7 14:13:12 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8848937B401; Mon, 7 Jul 2003 14:13:12 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA4CF43FBD; Mon, 7 Jul 2003 14:13:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <20030707211310013007u5ehe>; Mon, 7 Jul 2003 21:13:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA14501; Mon, 7 Jul 2003 14:13:09 -0700 (PDT) Date: Mon, 7 Jul 2003 14:13:08 -0700 (PDT) From: Julian Elischer To: David Schultz In-Reply-To: <20030707082506.GA90638@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David Xu cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_get_np.cthr_cancel.cthr_sigaction.c thr_sigmask.c thr_sigpending.c thr_sigsuspend.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 21:13:13 -0000 On Mon, 7 Jul 2003, David Schultz wrote: > On Mon, Jul 07, 2003, David Xu wrote: > > > > davidxu 2003/07/06 21:28:23 PDT > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > lib/libpthread/thread thr_attr_get_np.c thr_cancel.c > > > > thr_getschedparam.c thr_join.c > > > > thr_mutex_prioceiling.c thr_sigaction.c > > > > thr_sigmask.c thr_sigpending.c > > > > thr_sigsuspend.c > > > > Log: > > > > Avoid accessing user provided parameters in critical region. > > > > > > Cool. What happens if a page fault is taken in a critical region? > > > Does this merely make the KSE unusable by other threads until the > > > page is faulted in, or does it deadlock the UTS? (If the latter > > > is true, you'd need to wire a stack page or two to ensure > > > correctness, or do soemthing differently.) > > > > > > > The change is nothing to do with page fault, also page fault > > shouldn't cause deadlock. It is true the kse can not be used > > by other threads if page fault occurs while in critical region. > > For normal page fault not in critical region, kernel KSE codes > > still does not call thread_user_enter(), but I want to insert > > such call in trap.c, so when a page fault occurs, and thread > > is blocked in paging, other threads still can run in userland, > > if a user thread is in kernel mode, it is not affected. > > That's what I was talking about. If you enter the UTS upon taking > a page fault, you have to be sure that the page that faulted > didn't belong to the UTS itself, or you at least have to have some > way of breaking the loop. But since the UTS is unaware of page > faults presently, I guess this isn't a problem yet. > By definition, (i.e the definition of how upcalls are done) a page fault in the UTS would block until the page was loaded and no upcall would be produced.. This is because there is no registerred 'thread' in the UTS's mailbox when the kernel is enterred, so no upcall context can be created. (or, rather, the current context can not be storred for later so the current KSE is not free to create a new upcall context.)