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.
- Garrett
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
