On Tue, May 31, 2022 at 10:28 AM Yegor Yefremov
<yegorslists@xxxxxxxxxxxxxx> wrote:
> On Thu, May 5, 2022 at 7:03 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220504 09:12]:
> > > Hi Tony, all,
> > >
> > > During the kernel boot I see the following error. The device is still
> > > working afterwards. 5.17.5 shows the same behavior. Is this a known
> > > issue?
> >
> > Thanks for reporting it, I was not aware of this one. Might be worth
> > bisecting. Adding linux-mmc and Ulf.
>
> After enabling the CONFIG_DMA_API_DEBUG option, I also get the following error:
> [ 7.603288] dma_map_sg_attrs from sdhci_pre_dma_transfer+0xcc/0x134
> [ 7.609705] sdhci_pre_dma_transfer from mmc_blk_mq_issue_rq+0x2f4/0xa58
> [ 7.616462] mmc_blk_mq_issue_rq from mmc_mq_queue_rq+0x124/0x258
> [ 7.622604] mmc_mq_queue_rq from blk_mq_dispatch_rq_list+0x1b8/0x8ac
> [ 7.629104] blk_mq_dispatch_rq_list from
> blk_mq_do_dispatch_sched+0x2ec/0x350
> [ 7.636387] blk_mq_do_dispatch_sched from
> __blk_mq_sched_dispatch_requests+0x118/0x170
> [ 7.644448] __blk_mq_sched_dispatch_requests from
> blk_mq_sched_dispatch_requests+0x34/0x5c
> [ 7.652859] blk_mq_sched_dispatch_requests from
> __blk_mq_run_hw_queue+0xf8/0x230
> [ 7.660402] __blk_mq_run_hw_queue from process_one_work+0x284/0x72c
This is the blk_mq code taking things off the queue, so we don't really
know how they got put on there at this point. To find that, we'd need to
annotate the mmc code with the same kind of check to test the buffer
address whenever something gets submitted on the blk_mq queue.
Looking at the calls to sg_init*(), I found sdio_io_rw_ext_helper(), which
is what all sdio commands pass through. We could annotate that using
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 79dbf90216b5..4ab063c50649 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -322,6 +322,11 @@ static int sdio_io_rw_ext_helper(struct sdio_func
*func, int write,
if (!func || (func->num > 7))
return -EINVAL;
+ WARN_ON_ONCE(memory_intersects(_stext, _etext, buf, size));
+ WARN_ON_ONCE(memory_intersects(__start_rodata, __end_rodata,
buf, size));
+ WARN_ON_ONCE(object_is_on_stack(buf));
+ WARN_ON_ONCE(is_vmalloc_or_module_addr(buf));
+
/* Do the bulk of the transfer using block mode (if supported). */
if (func->card->cccr.multi_block && (size > sdio_max_byte_size(func))) {
/* Blocks per command is limited by host count, host transfer
Does that show something new?
If this is a block device, the change won't help, but I can't find a good place
to hook into that at the moment. mmc_mq_queue_rq() might work, but
I think that is still called asynchronously.
Arnd
