Re: ahci 0000:00:1f.2: DMA-API: device driver maps memory from stack

[Robert Hancock <hancockrwd@gmail.com>]

Chuck Ebbert wrote:
> With v3 of the DMA API debug patchset:
> 
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:515 check_for_stack+0x78/0x9a() (Not tainted)
> Hardware name: 74585FU
> ahci 0000:00:1f.2: DMA-API: device driver maps memory from stack
> [addr=ffff880137929c00]
> Modules linked in:
> Pid: 645, comm: scsi_eh_1 Not tainted 2.6.29-0.172.rc6.git4.fc11.x86_64 #1
> Call Trace:
>  [<ffffffff8104ba7b>] warn_slowpath+0xbc/0xf0
>  [<ffffffff81060061>] ? sys_timer_gettime+0x80/0x9b
>  [<ffffffff8101781b>] ? native_sched_clock+0x2d/0x5a
>  [<ffffffff810170b5>] ? sched_clock+0x9/0xc
>  [<ffffffff811a72a0>] ? dma_entry_alloc+0x7e/0x86
>  [<ffffffff81395baf>] ? _spin_unlock_irqrestore+0x41/0x58
>  [<ffffffff811a6677>] check_for_stack+0x78/0x9a
>  [<ffffffff811a73f3>] debug_dma_map_sg+0xd8/0x104
>  [<ffffffff81263b0a>] ata_qc_issue+0x1f3/0x289
>  [<ffffffff812641ce>] ? ata_exec_internal_sg+0x8c/0x4dc
>  [<ffffffff812643c0>] ata_exec_internal_sg+0x27e/0x4dc
>  [<ffffffff81395bb6>] ? _spin_unlock_irqrestore+0x48/0x58
>  [<ffffffff812646ab>] ata_exec_internal+0x8d/0x9c
>  [<ffffffff81393b89>] ? wait_for_common+0xcc/0x110
>  [<ffffffff8126adb6>] atapi_eh_request_sense+0x9f/0xa8
>  [<ffffffff8126dad8>] ata_eh_recover+0x92d/0xbbe
>  [<ffffffff8106f4e5>] ? mark_lock+0x28/0x37f
>  [<ffffffff812750aa>] ? ahci_postreset+0x0/0x5f
>  [<ffffffff8127467f>] ? ahci_hardreset+0x0/0xeb
>  [<ffffffff812765fe>] ? ahci_softreset+0x0/0x42
>  [<ffffffff81263052>] ? ata_std_prereset+0x0/0xb7
>  [<ffffffff81271e7b>] sata_pmp_error_handler+0xd3/0xa0a
>  [<ffffffff8101781b>] ? native_sched_clock+0x2d/0x5a
>  [<ffffffff8101781b>] ? native_sched_clock+0x2d/0x5a
>  [<ffffffff810170b5>] ? sched_clock+0x9/0xc
>  [<ffffffff8106e001>] ? lock_release_holdtime+0x2c/0x11d
>  [<ffffffff81395bb6>] ? _spin_unlock_irqrestore+0x48/0x58
>  [<ffffffff812750a6>] ahci_error_handler+0x4a/0x4e
>  [<ffffffff8126e7a8>] ata_scsi_error+0x2c0/0x619
>  [<ffffffff8124d189>] scsi_error_handler+0xdd/0x4fe
>  [<ffffffff81395bb6>] ? _spin_unlock_irqrestore+0x48/0x58
>  [<ffffffff8106fa96>] ? trace_hardirqs_on_caller+0x12f/0x153
>  [<ffffffff8106fac7>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff8124d0ac>] ? scsi_error_handler+0x0/0x4fe
>  [<ffffffff81060881>] kthread+0x4d/0x78
>  [<ffffffff810126aa>] child_rip+0xa/0x20
>  [<ffffffff8100f88b>] ? __switch_to+0x190/0x398
>  [<ffffffff81011fbe>] ? restore_args+0x0/0x30
>  [<ffffffff81060834>] ? kthread+0x0/0x78
>  [<ffffffff810126a0>] ? child_rip+0x0/0x20
> ---[ end trace 88a6b0f8de8d369d ]---
> 
> AFAICT it's complaining about ata_exec_internal(),
> which puts 'sg' on the stack, assigns 'psg' the
> address of 'sg' and passes that pointer to lower
> level code:
> 
> unsigned ata_exec_internal(struct ata_device *dev,
>                            struct ata_taskfile *tf, const u8 *cdb,
>                            int dma_dir, void *buf, unsigned int buflen,
>                            unsigned long timeout)
> {
>         struct scatterlist *psg = NULL, sg;
>         unsigned int n_elem = 0;
> 
>         if (dma_dir != DMA_NONE) {
>                 WARN_ON(!buf);
>                 sg_init_one(&sg, buf, buflen);
>                 psg = &sg;
>                 n_elem++;
>         }
> 
>         return ata_exec_internal_sg(dev, tf, cdb, dma_dir, psg, n_elem,
>                                     timeout);
> }

I don't think that's it, we're not DMAing from that pointer.. It seems 
more likely that the sense buffer (which is where the data is being put) 
somehow resides on the stack. One could print out where buf points in 
this function and see if that is the case. Sense buffer gets allocated 
by the SCSI layer..