Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Jul 2003 13:53:35 +0800
From:      "David Xu" <davidxu@viatech.com.cn>
To:        "Alfred Perlstein" <bright@mu.org>
Cc:        cvs-all@FreeBSD.org
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
Message-ID:  <004301c3444c$1ae0f6e0$f001a8c0@davidw2k>
References:  <200307070428.h674SNfq092785@repoman.freebsd.org> <20030707044204.GM72093@elvis.mu.org> <005f01c34442$f9091c40$f001a8c0@davidw2k> <20030707054153.GN72093@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

----- Original Message -----=20
From: "Alfred Perlstein" <bright@mu.org>
To: "David Xu" <davidxu@viatech.com.cn>
Cc: <src-committers@FreeBSD.org>; <cvs-src@FreeBSD.org>; =
<cvs-all@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.
> > >=20
> > > Interesting, is this to avoid pagefaults during critical sections
> > > inside userspace?
> > >=20
> > Yes.
>=20
> Sorry to yammer out a bunch of questions out of the blue, but I'm
> trying to understand:
>=20
> 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?
>=20

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=20
would make libkse more sane when it encounters SIGSEGV.

David Xu

> --=20
> -Alfred Perlstein [alfred@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.'



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004301c3444c$1ae0f6e0$f001a8c0>