Hi, On Thu, May 21, 2020 at 04:01:04PM +0900, Yoshihiro Shimoda wrote: > Related drivers like renesas_sdhi_internal_dmac are possible > to lack dma unmaping in error cases (for example response timeout). > > Since tmio_mmc_finish_request() will be always called in any case, > to fix the issue, add end operation into struct tmio_mmc_dma_ops and > call the operation in tmio_mmc_finish_request() to call dma_ummap API > by the related drivers correctly. > > Signed-off-by: Yoshihiro Shimoda > --- > drivers/mmc/host/tmio_mmc.h | 3 +++ > drivers/mmc/host/tmio_mmc_core.c | 8 ++++++++ > 2 files changed, 11 insertions(+) > > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h > index b4cf101..0a4f365 100644 > --- a/drivers/mmc/host/tmio_mmc.h > +++ b/drivers/mmc/host/tmio_mmc.h > @@ -118,6 +118,9 @@ struct tmio_mmc_dma_ops { > void (*release)(struct tmio_mmc_host *host); > void (*abort)(struct tmio_mmc_host *host); > void (*dataend)(struct tmio_mmc_host *host); > + > + /* optional */ > + void (*end)(struct tmio_mmc_host *host); /* held host->lock */ Okay, the good news is that I can reproduce the error case. I also get a growing list in /sys/kernel/debug/dma-api/dump. However, here, the list does not grow at the same rate as the fake timeouts are injected. So, it doesn't look like the unmapping is missed every time but only occasionally, so this seems like a race somewhere? And if that is true, I wonder if we couldn't fix the current error paths instead of adding another callback? Or do you get a missed unmap for every timeout, Shimoda-san? All the best, Wolfram