linux-kernel - Re: [PATCH v4 1/5] mm: cma: add trace events to debug physically-contiguous memory allocations

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: <20150319163406.4050cdaf@gandalf.local.home>
Date:	Thu, 19 Mar 2015 16:34:06 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Stefan Strogin <s.strogin@...tner.samsung.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	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>,
	Aleksei Mateosian <a.mateosian@...sung.com>,
	gregory.0xf0@...il.com, sasha.levin@...cle.com, gioh.kim@....com,
	pavel@....cz, stefan.strogin@...il.com,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v4 1/5] mm: cma: add trace events to debug
 physically-contiguous memory allocations

On Thu, 19 Mar 2015 23:18:18 +0300
Stefan Strogin <s.strogin@...tner.samsung.com> wrote:

> Thank you for the reply, Steven.
> I supposed that page_to_pfn() cannot change after mem_map
> initialization, can it? I'm not sure about such things as memory hotplug
> though...
> Also cma_alloc() calls alloc_contig_range() which returns pfn, then it's
> converted to struct page * and cma_alloc() returns struct page *, and
> vice versa in cma_release() (receives struct page * and passes pfn to
> free_contig_rage()).
> Do you mean that printing pfn (or struct page *) in trace event is
> redundant?

I'm concerned about the time TP_printk() is executed and when
TP_fast_assign() is. That is, when the tracepoint is called,
TP_fast_assign() is executed, but TP_printk() is called when someone
reads the trace files, which can happen seconds, hours, days, weeks,
months later.

As long as the result of page_to_pfn() and pfn_to_page() stay the same
throughout the life of the boot, things will be fine. But if they could
ever change, due to hotplug memory or whatever. The data in the trace
buffer will become stale, and report the wrong information.

-- Steve
--
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/