On Tue, May 31, 2022 at 11:23 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> 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.
No, the patch provides the same output.
Yegor
