From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Woodhouse, David" <david.woodhouse@intel.com>
Cc: Chris Boot <bootc@bootc.net>, adam radford <aradford@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
Adam Radford <linuxraid@lsi.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: iommu_iova leak [inside 3w-9xxx]
Date: Sun, 18 Sep 2011 18:01:49 +0400 [thread overview]
Message-ID: <1316354509.27722.1.camel@dabdike> (raw)
In-Reply-To: <1316353140.12001.15.camel@shinybook.infradead.org>
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
next prev parent reply other threads:[~2011-09-18 14:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E734467.3040703@bootc.net>
[not found] ` <1316256305.24257.25.camel@shinybook.infradead.org>
[not found] ` <AD4B8103-C98F-4BC5-9F7F-496D220781F3@bootc.net>
2011-09-17 14:29 ` iommu_iova leak [inside 3w-9xxx] Chris Boot
2011-09-17 19:22 ` adam radford
2011-09-17 19:31 ` Woodhouse, David
2011-09-17 20:17 ` Chris Boot
2011-09-18 12:06 ` Chris Boot
2011-09-18 13:39 ` Woodhouse, David
2011-09-18 14:01 ` James Bottomley [this message]
2011-09-18 14:05 ` Chris Boot
2011-09-18 14:25 ` James Bottomley
2011-09-18 14:56 ` James Bottomley
2011-09-18 16:19 ` Chris Boot
2011-09-19 15:32 ` Chris Boot
2011-09-19 19:26 ` adam radford
2011-09-19 20:54 ` Chris Boot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1316354509.27722.1.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=aradford@gmail.com \
--cc=bootc@bootc.net \
--cc=david.woodhouse@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxraid@lsi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox