On 2021-10-19 13:32:42 [+0200], Ulf Hansson wrote: > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > > index 431af5e8be2f8..7d6b43fe52e8a 100644 > > --- a/drivers/mmc/core/block.c > > +++ b/drivers/mmc/core/block.c > > @@ -2178,7 +2183,8 @@ static void mmc_blk_mq_req_done(struct mmc_request *mrq) > > mq->rw_wait = false; > > wake_up(&mq->wait); > > > > - mmc_blk_mq_post_req(mq, req); > > + /* context unknown */ > > + mmc_blk_mq_post_req(mq, req, false); > > So it seems we would benefit from knowing the context here, right? Yes. > At this point, what you suggest seems like a reasonable way forward > (assuming atomic context), but in a next step we could potentially add > a non-atomic helper function for mmc host drivers to call, when that > is suitable. Would that make sense you think? Sure. I didn't mange to figure where this can be called from so I assumed atomic so it behaves the way it did. If you can provide additional information here then the additional scheduling of ksoftirqd could be avoided. Also, if there are drivers which complete their requests in a threaded-irq handler, then the softirq could be also avoided (there should be no irq-disabling then). I *think* there were other completion paths, I just touched the one I managed to reproduce. > > Kind regards > Uffe Sebastian
