lkml.org 
[lkml]   [2011]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: iommu_iova leak [inside 3w-9xxx]
From
Date
On 18 Sep 2011, at 15:01, James Bottomley wrote:
> On Sun, 2011-09-18 at 13:39 +0000, Woodhouse, David wrote:
>> On Sun, 2011-09-18 at 13:06 +0100, Chris Boot wrote:
>>> On 17 Sep 2011, at 20:22, adam radford wrote:
>>>> On Sat, Sep 17, 2011 at 7:29 AM, Chris Boot <bootc@bootc.net> wrote:
>>>>> On 17 Sep 2011, at 12:57, Chris Boot wrote:
>>>>>> On 17 Sep 2011, at 11:45, Woodhouse, David wrote:
>>>>>>> I suppose it's vaguely possible that we're leaking them in such a way
>>>>>>> that they remain on the rbtree, perhaps if the deferred unmap is never
>>>>>>> actually happening... but I think it's a whole lot more likely that the
>>>>>>> PCI driver is just never bothering to unmap the pages it maps.
>>>>
>>>> If you think 3w-9xxx is not unmapping pages it maps, please re-run with
>>>> CONFIG_PCI_DMA_DEBUG=y
>>>
>>> Adam,
>>>
>>> I installed a fresh Debian system on a SATA disk connected to the built-in SATA controller, then played with loading/unloading the 3w-9xxx module and doing a few basic things. Without even prodding very much, I got this result:
>>>
>>> [ 1142.363173] ------------[ cut here ]------------
>>> [ 1142.368507] WARNING: at lib/dma-debug.c:697 dma_debug_device_change+0x172/0x1a6()
>>> [ 1142.377162] Hardware name: S1200BTL
>>> [ 1142.381193] pci 0000:01:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=37]
>>> [ 1142.381194] One of leaked entries details: [device address=0x00000000fff9a000] [size=4096 bytes] [mapped with DMA_TO_DEVICE] [mapped as scather-gather]
>> ...
>>> [ 1142.381254] Mapped at:
>>> [ 1142.381255] [<ffffffff811c35b1>] debug_dma_map_sg+0x3b/0x140
>>> [ 1142.381256] [<ffffffffa00cb0db>] scsi_dma_map+0x9b/0xb7 [scsi_mod]
>>> [ 1142.381260] [<ffffffffa012c675>] twa_scsiop_execute_scsi+0x141/0x3a5 [3w_9xxx]
>>> [ 1142.381263] [<ffffffffa012ce3b>] twa_scsi_queue+0xd6/0x16a [3w_9xxx]
>>> [ 1142.381265] [<ffffffffa00c4620>] scsi_dispatch_cmd+0x192/0x236 [scsi_mod]
>>
>> Seems like a smoking gun to me, although at first glance I can't see an
>> *obvious* leak in the 3w-9xxx code. Adam?
>
> Hardly ... all it's saying is that twa_exit doesn't wait for pending I/O
> to complete, so when you remove the module it tears down in the middle
> of an I/O. A bug, yes, but it's not indicative of any sort of leak in
> the maps/unmaps.


James,

I don't think that's the case - I had unmounted all filesystems, deactivated all volume groups, and performed a sync before waiting a few seconds and running rmmod. Next time I'll also 'echo 1 > /sys/block/sdX/device/delete' if that's helpful.

Chris

--
Chris Boot
bootc@bootc.net



\
 
 \ /
  Last update: 2011-09-18 16:07    [W:0.035 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site