linux-kernel - Re: [RFC PATCH 1/1] kernel/events: Introduce IOC_COUNT

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:   Tue, 6 Jun 2017 22:26:44 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/1] kernel/events: Introduce IOC_COUNT_RECORDS

Hi Arnaldo,

On 2017/06/06 12:51PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 06, 2017 at 08:46:28PM +0530, Naveen N. Rao escreveu:
> > Many perf sideband events (context switches, namespaces, ...) are useful
> > by themselves without the need for subscribing to any overflow events.
> > However, it is not possible to subscribe for notifications when such
> > records are logged into the ring buffer. Introduce IOC_COUNT_RECORDS as
> > a way to request this.
> > 
> > With IOC_COUNT_RECORDS set, IOC_REFRESH takes the number of records
> > after which to generate a notification, rather than the number of
> > overflow events.
> 
> Can you take a look at tools/perf/python/twatch.py?
> 
> [acme@...et linux]$ make O=/tmp/build/perf -C tools/perf install-bin
> [root@...et linux]# export PYTHONPATH=/tmp/build/perf/python/
> [root@...et linux]# python tools/perf/python/twatch.py
> cpu:  0, pid: 29860, tid: 29860 { type: exit, pid: 29860, ppid: 29860, tid: 29860, ptid: 29860, time: 117729363047027}
> cpu:  0, pid: 29854, tid: 29854 { type: exit, pid: 29854, ppid: 29854, tid: 29854, ptid: 29854, time: 117729363617885}
> cpu:  0, pid: 29853, tid: 29853 { type: fork, pid: 29865, ppid: 29853, tid: 29865, ptid: 29853, time: 117729363800225}
> cpu:  0, pid: 29865, tid: 29865 { type: comm, pid: 29865, tid: 29865, comm: fixdep }
> cpu:  0, pid: 29865, tid: 29865 { type: exit, pid: 29865, ppid: 29865, tid: 29865, ptid: 29865, time: 117729364898505}
> cpu:  0, pid: 29853, tid: 29853 { type: fork, pid: 29866, ppid: 29853, tid: 29866, ptid: 29853, time: 117729365022416}
> cpu:  0, pid: 29866, tid: 29866 { type: comm, pid: 29866, tid: 29866, comm: rm }
> cpu:  0, pid: 29866, tid: 29866 { type: exit, pid: 29866, ppid: 29866, tid: 29866, ptid: 29866, time: 117729365665831}
> cpu:  0, pid: 29853, tid: 29853 { type: fork, pid: 29867, ppid: 29853, tid: 29867, ptid: 29853, time: 117729365846030}
> cpu:  0, pid: 29867, tid: 29867 { type: comm, pid: 29867, tid: 29867, comm: mv }
> cpu:  2, pid: 28218, tid: 28218 { type: exit, pid: 28218, ppid: 28218, tid: 28218, ptid: 28218, time: 117729704900029}
> ^CTraceback (most recent call last):
>   File "tools/perf/python/twatch.py", line 68, in <module>
>     main()
>   File "tools/perf/python/twatch.py", line 40, in main
>     evlist.poll(timeout = -1)
> KeyboardInterrupt
> [root@...et linux]#
> 
> This is using the python binding to get notifications for such meta
> events "synchronously", you can do the same with a C proggie, of course,
> and using just what we have in the kernel already.
> 
> See its changelog comments to see examples:
> 
> git log tools/perf/python/twatch.py
> 
> For instance, what I think you want is in:
> 
> [acme@...et linux]$ git log --oneline -1 cfeb1d90a1b1db96383b48888cb7a5f10ca12e12
> cfeb1d90a1b1 perf python: Use attr.watermark in twatch.py
> [acme@...et linux]$ git log --oneline -1 58b32c1b538f2d197ce385d6a314e83f8b787021
> 58b32c1b538f perf python: Make twatch.py use soft dummy event, freq=0
> [acme@...et linux]$

Thanks. I did come across the above commits when I was looking into 
this. And this is very close to what I was looking for, but the key 
difference is that I want to be notified through a signal, rather than 
having to use poll()/select(). This is for self-profiling, so a process 
won't need a separate thread for monitoring the mmap buffer.

- Naveen