cvs commit: src/lib/libpthread/thread thr_attr_get_np.cthr_cancel.cthr_sigaction.c thr_sigmask.c thr_sigpending.c thr_sigsuspend.c

Daniel Eischen eischen at vigrid.com
Mon Jul 7 05:56:30 PDT 2003


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.

When we're in the UTS, upcalls are blocked so a page fault
in the UTS doesn't matter; that KSE will not run until the
page is present.

The code questioned is when we are not in the UTS but have
a current thread.  We block upcalls when threads are in
critical regions (so the thread won't be swapped out
onto a different KSE by the kernel).  In those regions,
we can page fault and the KSE will not run again until
the page is present (just like above), but we don't want
a SEGV caused by an application parameter.  If we get
a SEGV, the KSE will not run again (because upcalls
are blocked) and the application will not get the signal.

-- 
Dan Eischen



More information about the cvs-src mailing list