cvs commit: src/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

[David Xu]

----- Original Message ----- 
From: "Alfred Perlstein" <bright at mu.org>
To: "David Xu" <davidxu at viatech.com.cn>
Cc: <src-committers at FreeBSD.org>; <cvs-src at FreeBSD.org>; <cvs-all at FreeBSD.org>
Sent: Monday, July 07, 2003 1:41 PM
Subject: Re: cvs commit: src/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.
> > > 
> > > Interesting, is this to avoid pagefaults during critical sections
> > > inside userspace?
> > > 
> > Yes.
> 
> Sorry to yammer out a bunch of questions out of the blue, but I'm
> trying to understand:
> 
> Is that completely necessary?  I mean, isn't it likely that these
> arguements are paged in since they are parameters that have just
> been touched by the process?  What if there's paging pressure and
> the stack gets paged out anyway?  Is there something protecting
> that from happening?  I mean, I know it would be unpleasant to
> fault, but the code should be able to handle this right?
> 

No, sorry for confusing, it is used to avoid SIGSEGV in critical region,
because thread is holding low level locks or in critical region, SIGSEGV
can not delivered and possible causes deadlock.
This change can not 100% avoid the problem, but in most cases, this 
would make libkse more sane when it encounters SIGSEGV.

David Xu

> -- 
> -Alfred Perlstein [alfred at freebsd.org]
> 'Instead of asking why a piece of software is using "1970s technology,"
>  start asking why software is ignoring 30 years of accumulated wisdom.'