linux-kernel - Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc

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]

Message-ID: <510018B4.9040903@web.de>
Date:	Wed, 23 Jan 2013 18:07:00 +0100
From:	Soeren Moch <smoch@....de>
To:	Andrew Lunn <andrew@...n.ch>
CC:	Arnd Bergmann <arnd@...db.de>, Jason Cooper <jason@...edaemon.net>,
	Greg KH <gregkh@...uxfoundation.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>,
	linux-mm@...ck.org, Kyungmin Park <kyungmin.park@...sung.com>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linaro-mm-sig@...ts.linaro.org,
	linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent()
 calls

On 23.01.2013 17:25, Andrew Lunn wrote:
> On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
>> On 19.01.2013 19:59, Andrew Lunn wrote:
>>>> Please find attached a debug log generated with your patch.
>>>>
>>>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>>>> no ethernet cable connected, tuners on saa716x-based card not used.
>>>>
>>>> What I can see in the log: a lot of coherent mappings from sata_mv
>>>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>>>> All coherent mappings are page aligned, some of them (from orion_ehci)
>>>> are not really small (as claimed in __alloc_from_pool).
>>>>
>>>> I don't believe in a memory leak. When I restart vdr (the application
>>>> utilizing the dvb sticks) then there is enough dma memory available
>>>> again.
>>>
>>> Hi Soeren
>>>
>>> We should be able to rule out a leak. Mount debugfg and then:
>>>
>>> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
>>>
>>> while you are capturing. See if the number goes down.
>>>
>>>        Andrew
>>
>> Now I built a kernel with debugfs enabled.
>> It is not clear to me what I can see from the
>> dma-api/num_free_entries output. After reboot (vdr running) I see
>> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
>> lower (3390). Sometimes the output is constant for several minutes (
>> 3396 3396 3396 3396 3396,...)
>
> We are interesting in the long term behavior. Does it gradually go
> down? Or is it stable? If it goes down over time, its clearly a leak
> somewhere.
>

Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396 
3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3394 3396 3396 3396 3396 3396 3396 3396

Before the last pool exhaustion going down:
3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336 
3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265 
3247 3247 3247 3242 3236 3236

Soeren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/