On 07/18/2010 05:42 PM, Garrett D'Amore wrote:
Hi level interrupt context is "special".  There are really not very many
things you can do from there.  I think the only things you can count on
in high level interrupts are those functions that explicitly permit
*high level interrupt context* in their manual pages.

Anything that allocates memory (as ddi_taskq_dispatch does) would be
forbidden.  Even with KM_NOSLEEP.
OK, it seems I have no other choices.

Thanks for your prompt response.

On Sun, 2010-07-18 at 16:47 +0800, Oliver Yang wrote:
Hi Guys,

I called ddi_taskq_dispatch with DDI_NOSLEEP in the HIGH PIL
context and got a panic "dispatcher invoked from high-level
interrupt handler".

But the man page of taskq(9F) doesn't mention that the high PIL
context is forbidden.


CONTEXT
       All functions may be called from the  user  or  kernel  con-
       texts.

       Addtionally, the ddi_taskq_dispatch function may  be  called
       from  the  interrupt context only if the DDI_NOSLEEP flag is
       set.

I want to know whether it is an expected behavior, or it is an
implementation flaw/bug of existing taskq DDI?

Back to my usage case, I created an API whose consumer could
be a device driver or a kernel misc module.

This API might be called by an high PIL interrupt context, which
will cause the panic issue I mentioned above. In this case, if I
can find a way to create a separate kernel thread safely, then I
could get less limitations for my API usage.

In my previous understanding, taskq could meet my requirements,
but if it couldn't, do we have other ways to create a separate kernel
context in the high PIL interrupt context? You know, my code is
not existing in a device driver, soft interrupt is not a good choice
in this case.


_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code


_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to