linux-kernel - Re: [PATCH 3/3] Add name fields in shrinker tracepoint definitions

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: <447d8214-3c3d-cc4a-2eff-a47923fbe45f@suse.cz>
Date:	Mon, 11 Jul 2016 16:18:35 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Janani Ravichandran <janani.rvchndrn@...il.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc:	riel@...riel.com, akpm@...ux-foundation.org, hannes@...xchg.org,
	vdavydov@...tuozzo.com, mhocko@...e.com,
	mgorman@...hsingularity.net, kirill.shutemov@...ux.intel.com,
	bywxiaobai@....com
Subject: Re: [PATCH 3/3] Add name fields in shrinker tracepoint definitions

On 07/09/2016 11:05 AM, Janani Ravichandran wrote:
> Currently, the mm_shrink_slab_start and mm_shrink_slab_end
> tracepoints tell us how much time was spent in a shrinker, the number of
> objects scanned, etc. But there is no information about the identity of
> the shrinker. This patch enables the trace output to display names of
> shrinkers.
>
> ---
>  include/trace/events/vmscan.h | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
> index 0101ef3..be4c5b0 100644
> --- a/include/trace/events/vmscan.h
> +++ b/include/trace/events/vmscan.h
> @@ -189,6 +189,7 @@ TRACE_EVENT(mm_shrink_slab_start,
>  		cache_items, delta, total_scan),
>
>  	TP_STRUCT__entry(
> +		__field(char *, name)
>  		__field(struct shrinker *, shr)
>  		__field(void *, shrink)
>  		__field(int, nid)
> @@ -202,6 +203,7 @@ TRACE_EVENT(mm_shrink_slab_start,
>  	),
>
>  	TP_fast_assign(
> +		__entry->name = shr->name;
>  		__entry->shr = shr;
>  		__entry->shrink = shr->scan_objects;
>  		__entry->nid = sc->nid;
> @@ -214,7 +216,8 @@ TRACE_EVENT(mm_shrink_slab_start,
>  		__entry->total_scan = total_scan;
>  	),
>
> -	TP_printk("%pF %p: nid: %d objects to shrink %ld gfp_flags %s pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
> +	TP_printk("name: %s %pF %p: nid: %d objects to shrink %ld gfp_flags %s pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld",
> +		__entry->name,

Is this legal to do when printing is not done via the /sys ... file 
itself, but raw data is collected and then printed by e.g. trace-cmd? 
How can it possibly interpret the "char *" kernel pointer?

>  		__entry->shrink,
>  		__entry->shr,
>  		__entry->nid,
> @@ -235,6 +238,7 @@ TRACE_EVENT(mm_shrink_slab_end,
>  		total_scan),
>
>  	TP_STRUCT__entry(
> +		__field(char *, name)
>  		__field(struct shrinker *, shr)
>  		__field(int, nid)
>  		__field(void *, shrink)
> @@ -245,6 +249,7 @@ TRACE_EVENT(mm_shrink_slab_end,
>  	),
>
>  	TP_fast_assign(
> +		__entry->name = shr->name;
>  		__entry->shr = shr;
>  		__entry->nid = nid;
>  		__entry->shrink = shr->scan_objects;
> @@ -254,7 +259,8 @@ TRACE_EVENT(mm_shrink_slab_end,
>  		__entry->total_scan = total_scan;
>  	),
>
> -	TP_printk("%pF %p: nid: %d unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d",
> +	TP_printk("name: %s %pF %p: nid: %d unused scan count %ld new scan count %ld total_scan %ld last shrinker return val %d",
> +		__entry->name,
>  		__entry->shrink,
>  		__entry->shr,
>  		__entry->nid,
>