linux-kernel - Re: [RFC] perf tools: Add hugetlbfs memory recognition

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:	Mon, 29 Jun 2015 10:42:34 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Hou Pengyang <houpengyang@...wei.com>
Cc:	mingo@...hat.com, namhyung@...nel.org, a.p.zijlstra@...llo.nl,
	wangnan0@...wei.com, linux-kernel@...r.kernel.org,
	zhu.wen-jie@...com
Subject: Re: [RFC] perf tools: Add hugetlbfs memory recognition

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:
> > There is something about MAP_HUGETLB.
>  
> > In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
> > a bit in MMAP2 event.
>  
> > However, if mmap area is hugetlb related, MAP_HUGETLB does not always
> > appear. Because, there are two ways generating MMAP2 event.
>  
> > 1) when a new vm_area_struct is created, its info would be exported
> >    as a MMAP2 event.
> > 2) perf reads /proc/pid/maps for generating MMAP2 event.
>  
> > MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
> > while not on situation 2).
>  
> > This is because on situation 2), perf reads /proc/pid/maps, which
> > contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
> > details appear in /proc/pid/smaps, such as MAP_HUGETLB.
> 
> Humm:
> 
> [root@zoo ~]# wc -l /proc/`pidof firefox`/maps
> 934 /proc/4551/maps
> [root@zoo ~]# wc -l /proc/`pidof firefox`/smaps
> 14944 /proc/4551/smaps
> [root@zoo ~]#
>  
> > So I wonder if there is a need to read /proc/pid/smaps instead of
> > /proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
> > another way?
> 
> Doing some research now...

Bummer, seems that only smaps -> ... -> show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:

[root@zoo ~]# find /proc -name smaps | xargs grep -w ht
grep: /proc/31971/task/31971/smaps: No such file or directory
grep: /proc/31971/smaps: No such file or directory
[root@zoo ~]#

No "ht" HugeTLB areas, so no need to parse 16 times more bytes than by
just using /proc/PID/maps.

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