On Jul 18, 2010, at 3:20 AM, Oliver Yang wrote: > 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.
It is not just allocating memory. Anything that grabs adaptive mutexes is forbidden as well. You can not use taskq in high-level interrupt context, but you can post a soft interrupt instead and call taskq from soft interrupt if you need to. >> > 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 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
