linux-kernel - Re: [PATCH v3 3/4] mm: cma: add list of currently allocated CMA buffers to debugfs

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: <54FEF163.6000602@partner.samsung.com>
Date:	Tue, 10 Mar 2015 16:28:03 +0300
From:	Stefan Strogin <s.strogin@...tner.samsung.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dmitry Safonov <d.safonov@...tner.samsung.com>,
	Pintu Kumar <pintu.k@...sung.com>,
	Weijie Yang <weijie.yang@...sung.com>,
	Laura Abbott <lauraa@...eaurora.org>,
	SeongJae Park <sj38.park@...il.com>,
	Hui Zhu <zhuhui@...omi.com>, Minchan Kim <minchan@...nel.org>,
	Dyasly Sergey <s.dyasly@...sung.com>,
	Vyacheslav Tyrtov <v.tyrtov@...sung.com>,
	Aleksei Mateosian <a.mateosian@...sung.com>,
	gregory.0xf0@...il.com, sasha.levin@...cle.com, gioh.kim@....com,
	pavel@....cz, stefan.strogin@...il.com
Subject: Re: [PATCH v3 3/4] mm: cma: add list of currently allocated CMA
 buffers to debugfs

Hi Aneesh,

On 03/03/15 12:16, Aneesh Kumar K.V wrote:
> Stefan Strogin <s.strogin@...tner.samsung.com> writes:
> 
>> When CONFIG_CMA_BUFFER_LIST is configured a file is added to debugfs:
>> /sys/kernel/debug/cma/cma-<N>/buffers contains a list of currently allocated
>> CMA buffers for each CMA region (N stands for number of CMA region).
>>
>> Format is:
>> <base_phys_addr> - <end_phys_addr> (<size> kB), allocated by <PID> (<comm>)
>>
>> When CONFIG_CMA_ALLOC_STACKTRACE is configured then stack traces are saved when
>> the allocations are made. The stack traces are added to cma/cma-<N>/buffers
>> for each buffer list entry.
>>
>> Example:
>>
>> root@...ian:/sys/kernel/debug/cma# cat cma-0/buffers
>> 0x2f400000 - 0x2f417000 (92 kB), allocated by pid 1 (swapper/0)
>>  [<c1142c4b>] cma_alloc+0x1bb/0x200
>>  [<c143d28a>] dma_alloc_from_contiguous+0x3a/0x40
>>  [<c10079d9>] dma_generic_alloc_coherent+0x89/0x160
>>  [<c14456ce>] dmam_alloc_coherent+0xbe/0x100
>>  [<c1487312>] ahci_port_start+0xe2/0x210
>>  [<c146e0e0>] ata_host_start.part.28+0xc0/0x1a0
>>  [<c1473650>] ata_host_activate+0xd0/0x110
>>  [<c14881bf>] ahci_host_activate+0x3f/0x170
>>  [<c14854e4>] ahci_init_one+0x764/0xab0
>>  [<c12e415f>] pci_device_probe+0x6f/0xd0
>>  [<c14378a8>] driver_probe_device+0x68/0x210
>>  [<c1437b09>] __driver_attach+0x79/0x80
>>  [<c1435eef>] bus_for_each_dev+0x4f/0x80
>>  [<c143749e>] driver_attach+0x1e/0x20
>>  [<c1437197>] bus_add_driver+0x157/0x200
>>  [<c14381bd>] driver_register+0x5d/0xf0
>> <...>
> 
> A perf record -g will also give this information right ? To use this
> feature, one need to recompile the kernel anyway. So why not assume that
> user can always rerun the test with perf record -g and find the cma
> allocation point stack trace ?
> 
> -aneesh
> 

Excuse me for the delay.
I thought that 'perf record <command>' gathers data only for a command
that it runs, does it? But we want to have information about all the
allocations and releases from the boot time. IMHO it would be more
reasonable to use ftrace for that. But after all the patch enables to
see not a history of allocations and deallocations but a current state
of CMA region.
As to recompilation, for example in our division this feature is enabled
by default among other CONFIG_*_DEBUG features in debug versions of kernel.
--
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/