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:   Fri, 20 Aug 2021 02:18:29 +0800
From:   Gang Li <ligang.bdlg@...edance.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Axel Rasmussen <axelrasmussen@...gle.com>
Cc:     Axel Rasmussen <axelrasmussen@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH 3/3] mm: mmap_lock: add ip to mmap_lock tracepoints

On 8/2/21 10:44 AM, Gang Li wrote:
> On 7/31/21 4:03 AM, Steven Rostedt wrote:
>> Yes, synthetic events are just like normal events, and have triggers,
>> stack traces, and do pretty much anything that another event can do.
>>
>> I'm just finishing up a libtracfs called tracefs_sql() (hopefully
>> posting it today), that allows you to create a synthetic event via an
>> SQL statement. But I don't think this is what you are looking for.
>>
>> What about using function tracing? Because the tracepoint is called
>> from __mmap_lock* helper functions that function tracer can see, you
>> can just do the following:
>>
>>   # trace-cmd start -e mmap_lock -p function -l '__mmap_lock_*'
>>   # trace-cmd show
>> [..]
>>         trace-cmd-1840    [006] ....   194.576801: 
>> __mmap_lock_do_trace_start_locking <-do_user_addr_fault
>>         trace-cmd-1840    [006] ...1   194.576805: 
>> mmap_lock_start_locking: mm=000000006515cb1f 
>> memcg_path=/user.slice/user-0.slice/session-2.scope write=false
>>
Hi!

I find that sometimes the output data is out of order, which leads to 
inaccurate time stamps and make it hard to analyse.

             node-953     [001] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
             node-955     [002] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
             node-956     [003] ....   203.823297: 
__mmap_lock_do_trace_start_locking <-do_user_addr_fault
             node-953     [001] ....   203.823297: 
mmap_lock_start_locking: mm=000000004395a005 
memcg_path=/user.slice/user-0.slice/session-1.scope write=false 
ip=do_user_addr_fault+0x270/0x4d0
             node-953     [001] ....   203.823298: 
__mmap_lock_do_trace_acquire_returned <-do_user_addr_fault

Is there any other way to collect ip in each event? It seems that adding 
"ip" fields is the only way to do this accurately and effectively.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ