On Mon, Jun 08, 2020 at 09:42:54AM -0700, Christoph Hellwig wrote: > On Mon, Jun 08, 2020 at 06:40:09PM +0200, Peter Zijlstra wrote: > > There isn't one, it was meant to be used with static allocations. > > > > Frederic proposed changing all these to irq_work, and I think I'll go do > > that. First dinner though. OK, after having looked at this more, I think my initial analysis is actually wrong and this code should work as-is. The thing that I missed yesterday is that we only add the request to the blk_cpu_done list in the IPI, this means that the race I described earlier is not in fact possible. The IPI must happen for progress to be made. And the same is true for blk_mq_force_complete_rq(), which also uses this csd. > The irq_work API looks reasonable. What are the tradeoffs for > smp_call_single_async vs irq_work? To still answer your question; irq_work_queue*() has an atomic op extra that allows for more convenient semantics -- but is in your case strictly superfluous. Still, Jens' point about irq_work being smaller stands, and I think more users could benefit from something intermediate. Let me continue with the cleanups / audit and see what comes out at the end. Thanks!
