Subject: Re: how do I tell if I'm on the interrupt stack?
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 09/05/2001 15:20:33
How invasive would it be to add/require a per-CPU
servicing_interrupt() call to all the ports?
Or perhaps safe_to_sleep()?
That is, in any given kernel context you could ask "is
it safe to call tsleep from here?" (which is separate
from the question "is it *wise* to call tsleep from
here" :-) )
-matt
On Wed, 5 Sep 2001, Jason R Thorpe wrote:
> On Wed, Sep 05, 2001 at 05:58:32PM -0400, Paul Marchione wrote:
>
> > I believe that this will work:
> >
> > if you test the curproc pointer, a zero value implies no process is currently
> > running,
>
> No, this doesn't work... curproc can be non-NULL in interrupt context. It
> would indicate which process was running on the CPU when the interrupt
> happened.
>
> > you would thus have hit the code path from the kernel's hardclock function.
> >
> > i.e.
> >
> > if (!curproc)
> > {
> > /* base level 0, unsafe to call tsleep */
> > return;
> > }
> >
> > -paul
> >
> > Matthew Jacob wrote:
> >
> > > I have several possible entry points into a code path in a driver which can
> > > decide whether to ltsleep for an event or poll. If I know I've entered via an
> > > interrupt (e.g., the device interrupt service routine)- I can mark state so
> > > that I don't attempt to ltsleep.
> > >
> > > But it turns out that there is a normal callback via hardclock (in scsipi)
> > > that I have no means of distinguishing from any other call. How can I tell if
> > > I'm on the interrupt stack and it's not safe to call ltsleep?
> > >
> > > -matt
> >
>
> --
> -- Jason R. Thorpe <thorpej@wasabisystems.com>
>