On Wed, Jun 1, 2022 at 8:49 AM Yegor Yefremov
<yegorslists@xxxxxxxxxxxxxx> wrote:
> On Wed, Jun 1, 2022 at 8:45 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Wed, Jun 1, 2022 at 8:08 AM Yegor Yefremov
> > <yegorslists@xxxxxxxxxxxxxx> wrote:
> > > 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
> > > >
> > > > + 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.
> >
> > Can you say what devices are attached to the mmc controller? Is it
> > an eMMC block device, an SDIO device, or both?
>
> From DTS point of view: MMC and WiFi (SDIO). Physically, only MMC
> (removable SDcard).
Ok, I see. Actually I suppose I should have ruled out SDIO as the source
of the problem because the backtrace clearly listed the blk_mq layer.
This might instead work:
index 4e67c1403cc9..e8f1d89bd019 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1401,6 +1401,11 @@ static void mmc_blk_data_prep(struct mmc_queue
*mq, struct mmc_queue_req *mqrq,
struct scatterlist *sg;
for_each_sg(brq->data.sg, sg, brq->data.sg_len, i) {
+ void *v = sg_virt(sg);
+
+ WARN_ONCE(memory_intersects(_stext, _etext, v,
sg->length), "dma in .text: %p\n", v);
+ WARN_ONCE(memory_intersects(__start_rodata,
__end_rodata, v, sg->length), "dma in .rodata: %p\n", v);
+
data_size -= sg->length;
if (data_size <= 0) {
sg->length += data_size;
Maybe also try passing "no_hash_pointers" on the command line to have
the warning
print the actual pointer value. If that is indeed part of the kernel
vmlinux image, you
should be able to find the address in System.map.
Arnd
