Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/compat/sa

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:

        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?
        triggered when we call sys_sched_yield(). We are in a system
        call context.
        generated within the context of the newly-blessed lwp. So curlwp
        should be stable as I understand it.
        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?
        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. ??
        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 

Take care,


Attachment: pgp4lCGxnJVer.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index