On Mon, Oct 27, 2008 at 11:25:37AM -0700, Bill Stouder-Studenmund wrote:
> On Mon, Oct 27, 2008 at 06:56:21PM +0100, Christoph Egger wrote:
> > Bill Stouder-Studenmund wrote:
> > > Module Name: src
> > > Committed By: wrstuden
> > > Date: Mon Oct 27 16:52:04 UTC 2008
> > >
> > > Modified Files:
> > > src/sys/compat/sa: compat_sa.c
> > >
> > > Log Message:
> > > Ok. Some calls to sa_upcall() pass in an 'l' that is not the current
> > > lwp. Our "no-upcall" flagging however accesses l_pflag, and so we
> > > can't access l->l_pflag. So access curlwp for the no-upcall-blocking
> > > part.
> >
> > If you want to be kernel preemptible safe, you must cache curlwp.
>
> Huh?
>
> How could this use of curlwp change? I want the context that the code
> currently is running in. While I understand I could get preempted, won't I
> have to come back to the context I was in in order to resume?
>
> If curlwp really can change in any of (well, just one of) the places that
> will call sa_upcall(), the correct answer is to disable preemption. The
> whole point of this change is to prevent BLOCKED upcalls from what we're
> doing.
Specifically, we deliver the following upcalls:
SA_UPCALL_NEWPROC
triggered either when we start SA up or when we increase
concurrency. curlwp will not be l in this case, and we will
be in a systemcall context. So curlwp should be stable, no?
SA_UPCALL_PREEMPTED
triggered when we call sys_sched_yield(). We are in a system
call context.
SA_UPCALL_BLOCKED
generated within the context of the newly-blessed lwp. So curlwp
should be stable as I understand it.
SA_UPCALL_UNBLOCKED
generated as the blessed lwp is returning to usermode, inside of
lwp_userret(). curlwp should be the kernel context that the
user thread is running on, and should be stable, shouldn't it?
SA_UPCALL_SIGNAL
Generated in kpsendsig(), which is in turn called from postsig()
or trapsignal(). I'll admit this is a bit questionable, but I
thought we delivered signals on the way to usermode. Well,
either we are delivering a signal because our thread did something
(like a SIGSEGV), in which case curlwp is the naughty thread,
or someone else (some other process?) sent us a signal and we
notice it while we're heading out to usermode, in which case
curlwp should be the heading-to-usermode lwp. ??
SA_UPCALL_SIGEV
generated when we notice a timer has fired. Called from
lwp_userret() so this should fall into the same category as
SA_UPCALL_UNBLOCKED I think.
I realize I just went into a lot of detail. Also, I'll admit I think I'm
right. However the reason for the detail isn't to beat you down, it's so
that if I'm wrong, you can PLEASE PLEASE point out where I'm wrong. ;-)
If I'm wrong, I think the thing to do is disable kernel preemption in
sa_upcall().
Take care,
Bill
Attachment:
pgp4lCGxnJVer.pgp
Description: PGP signature