linux-kernel - RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Aug 2015 07:42:46 +0000
From:	Chen Bough <Haibo.Chen@...escale.com>
To:	Jiri Slaby <jslaby@...e.cz>, Ulf Hansson <ulf.hansson@...aro.org>
CC:	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA
 leaks]

Hi Js,

I read your attached log and patch, yes, dma memory leak will happen when
more than one pre_request execute. The method of ++next->cookie is not good,
your patch seems good, but I still need some time to test the patch, because
you unmap the dma in sdhci_finish_data rather than the sdhci_post_req.

Anyway, thanks for report and debug this issue. I will give you my test result
ASAP.  

Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@...e.cz]
> Sent: Wednesday, August 05, 2015 11:12 PM
> To: Chen Haibo-B51421; Ulf Hansson
> Cc: linux-mmc@...r.kernel.org; Linux kernel mailing list
> Subject: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA
> leaks]
> 
> On 08/05/2015, 01:52 PM, Jiri Slaby wrote:
> >> Yes, I see:
> >> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
> >> after some time. The driver falls back to non-DMA transfers after that.
> >> It also generates a warning about that:
> >> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
> >> sdhci_prepare_data+0x8ec/0x900 [sdhci]()
> >
> > I am attaching a debug patch and a debug log. You can see where
> > 0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when
> > 'invalid cookie' error happens.
> 
> And you could see the cookie handling is totally bogus.
> 
> With this rewrite, I no longer see the problems. Could you confirm it
> still does the good job with respect to performance -- the numbers you
> mentioned in your commit.
> 
> Ulf, what do you think about the attached patch? (Do not look at the
> commented info prints.)
> 
> thanks,
> --
> js
> suse labs