> The above implies that one must be careful when applying a common > Linux practice, that is to defer interrupt handling from IRQ context > to tasklet context. Since tasklets are executed with interrupts > enabled, invoking ib_req_notify_cq(cq, IB_CQ_NEXT_COMP) from tasklet > context may cause concurrent execution of an IB IRQ with an IB > tasklet. So if ib_poll_cq() is invoked from tasklet context, the > entire polling loop has to be protected against concurrent execution. > As far as I know such protection against concurrent execution is not > necessary inside tasklets that handle other types of hardware.
Not sure that I follow the problem you're worried about. A given tasklet can only be running on one CPU at any one time -- if an interrupt occurs and reschedules the tasklet then it just runs again when it exits. Also I'm not sure I understand why this is special for IB hardware -- standard practice is for interrupt handlers to clear the interrupt source and reenable interrupts, so I don't see why the same thing you describe can't happen with any interrupt-generating device that defers work to a tasklet. - R. -- Roland Dreier <rola...@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
