On 2021-10-19 13:32:42 [+0200], Ulf Hansson wrote:

quoted

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