linux-kernel - Re: [PATCH 0/4] mm: cma: add some debug information for CMA

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:	Sat, 14 Feb 2015 16:40:36 +0900
From:	Gioh Kim <gioh.kim@....com>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Stefan Strogin <s.strogin@...tner.samsung.com>
CC:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	aneesh.kumar@...ux.vnet.ibm.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>,
	gregory.0xf0@...il.com, sasha.levin@...cle.com, pavel@....cz,
	stefan.strogin@...il.com
Subject: Re: [PATCH 0/4] mm: cma: add some debug information for CMA



2015-02-13 오후 12:03에 Joonsoo Kim 이(가) 쓴 글:
> On Fri, Feb 13, 2015 at 01:15:40AM +0300, Stefan Strogin wrote:
>> Hi all.
>>
>> Sorry for the long delay. Here is the second attempt to add some facility
>> for debugging CMA (the first one was "mm: cma: add /proc/cmainfo" [1]).
>>
>> This patch set is based on v3.19 and Sasha Levin's patch set
>> "mm: cma: debugfs access to CMA" [2].
>> It is also available on git:
>> git://github.com/stefanstrogin/cmainfo -b cmainfo-v2
>>
>> We want an interface to see a list of currently allocated CMA buffers and
>> some useful information about them (like /proc/vmallocinfo but for physically
>> contiguous buffers allocated with CMA).
>>
>> Here is an example use case when we need it. We want a big (megabytes)
>> CMA buffer to be allocated in runtime in default CMA region. If someone
>> already uses CMA then the big allocation can fail. If it happens then with
>> such an interface we could find who used CMA at the moment of failure, who
>> caused fragmentation (possibly ftrace also would be helpful here) and so on.
>
> Hello,
>
> So, I'm not sure that information about allocated CMA buffer is really
> needed to solve your problem. You just want to know who uses default CMA
> region and you can know it by adding tracepoint in your 4/4 patch. We
> really need this custom allocation tracer? What can we do more with
> this custom tracer to solve your problem? Could you more specific
> about your problem and how to solve it by using this custom tracer?
>
>>
>> These patches add some files to debugfs when CONFIG_CMA_DEBUGFS is enabled.
>
> If this tracer is justifiable, I think that making it conditional is
> better than just enabling always on CONFIG_CMA_DEBUGFS. Some users
> don't want to this feature although they enable CONFIG_CMA_DEBUGFS.
>
> Thanks.
>

Hello,

Thanks for your work. It must be helpful to me.

What about add another option to activate stack-trace?
In my platform I know all devices using cma area, so I usually don't need stack-trace.
--
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/