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: <20150316194750.04885ee7@grimm.local.home>
Date:	Mon, 16 Mar 2015 19:47:50 -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 Mon, 16 Mar 2015 23:49:01 +0300
Stefan Strogin <s.strogin@...tner.samsung.com> wrote:

> Oops... forgot to cc tracing maintainers. Sorry!

Thanks,

> 
> On 16/03/15 19:06, Stefan Strogin wrote:
> > Add trace events for cma_alloc() and cma_release().
> > 
> > Signed-off-by: Stefan Strogin <stefan.strogin@...il.com>
> > ---
> >  include/trace/events/cma.h | 57 ++++++++++++++++++++++++++++++++++++++++++++++
> >  mm/cma.c                   |  5 ++++
> >  2 files changed, 62 insertions(+)
> >  create mode 100644 include/trace/events/cma.h
> > 
> > diff --git a/include/trace/events/cma.h b/include/trace/events/cma.h
> > new file mode 100644
> > index 0000000..d88881b
> > --- /dev/null
> > +++ b/include/trace/events/cma.h
> > @@ -0,0 +1,57 @@
> > +#undef TRACE_SYSTEM
> > +#define TRACE_SYSTEM cma
> > +
> > +#if !defined(_TRACE_CMA_H) || defined(TRACE_HEADER_MULTI_READ)
> > +#define _TRACE_CMA_H
> > +
> > +#include <linux/types.h>
> > +#include <linux/tracepoint.h>
> > +
> > +TRACE_EVENT(cma_alloc,
> > +
> > +	TP_PROTO(struct cma *cma, struct page *page, int count),
> > +
> > +	TP_ARGS(cma, page, count),
> > +
> > +	TP_STRUCT__entry(
> > +		__field(struct page *, page)
> > +		__field(unsigned long, count)
> > +	),
> > +
> > +	TP_fast_assign(
> > +		__entry->page = page;
> > +		__entry->count = count;
> > +	),
> > +
> > +	TP_printk("page=%p pfn=%lu count=%lu",
> > +		  __entry->page,
> > +		  __entry->page ? page_to_pfn(__entry->page) : 0,

Can page_to_pfn(value) ever be different throughout the life of the
boot? That is, can it return a different result given the same value
(vmalloc area comes to mind).

> > +		  __entry->count)
> > +);
> > +
> > +TRACE_EVENT(cma_release,
> > +
> > +	TP_PROTO(struct cma *cma, unsigned long pfn, int count),
> > +
> > +	TP_ARGS(cma, pfn, count),
> > +
> > +	TP_STRUCT__entry(
> > +		__field(unsigned long, pfn)
> > +		__field(unsigned long, count)
> > +	),
> > +
> > +	TP_fast_assign(
> > +		__entry->pfn = pfn;
> > +		__entry->count = count;
> > +	),
> > +
> > +	TP_printk("pfn=%lu page=%p count=%lu",
> > +		  __entry->pfn,
> > +		  pfn_to_page(__entry->pfn),

Same here. Can pfn_to_page(value) ever return a different result with
the same value in a single boot?

-- Steve

> > +		  __entry->count)
> > +);
> > +
> > +#endif /* _TRACE_CMA_H */
> > +
> > +/* This part must be outside protection */
> > +#include <trace/define_trace.h>
> > diff --git a/mm/cma.c b/mm/cma.c
> > index 47203fa..63dfc0e 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -23,6 +23,7 @@
> >  #  define DEBUG
> >  #endif
> >  #endif
> > +#define CREATE_TRACE_POINTS
> >  
> >  #include <linux/memblock.h>
> >  #include <linux/err.h>
> > @@ -34,6 +35,7 @@
> >  #include <linux/cma.h>
> >  #include <linux/highmem.h>
> >  #include <linux/io.h>
> > +#include <trace/events/cma.h>
> >  
> >  #include "cma.h"
> >  
> > @@ -414,6 +416,8 @@ struct page *cma_alloc(struct cma *cma, unsigned int count, unsigned int align)
> >  		start = bitmap_no + mask + 1;
> >  	}
> >  
> > +	trace_cma_alloc(cma, page, count);
> > +
> >  	pr_debug("%s(): returned %p\n", __func__, page);
> >  	return page;
> >  }
> > @@ -446,6 +450,7 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
> >  
> >  	free_contig_range(pfn, count);
> >  	cma_clear_bitmap(cma, pfn, count);
> > +	trace_cma_release(cma, pfn, count);
> >  
> >  	return true;
> >  }
> > 

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