linux-kernel - [rfd] function-graph augmentation

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-next>] [day] [month] [year] [list]

Message-Id: <1235077304.4612.662.camel@laptop>
Date:	Thu, 19 Feb 2009 22:01:44 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Frederic Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <srostedt@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>
Subject: [rfd] function-graph augmentation

Hi,

I was thinking how best to augment the function graph tracer with
various information. It seemed useful to add argument/return tracer
entries which, when found after a function entry, or function exit entry
would be rendered in the trace.

So supposing something like;

 3)               |  handle_mm_fault() {                                        
 3)               |    count_vm_event() {                                       
 3)   0.243 us    |      test_ti_thread_flag();                                 
 3)   0.754 us    |    }                                                        
 3)   0.249 us    |    pud_alloc();                                             
 3)   0.251 us    |    pmd_alloc();                                             
 3)               |    __do_fault() {                                           
 3)               |      filemap_fault() {                                      
 3)               |        find_lock_page() {                                   
 3)               |          find_get_page() {                                  
 3)   0.248 us    |            test_ti_thread_flag();                           
 3)   0.844 us    |          }                                                  
 3)   1.341 us    |        }                                                    
 3)   1.837 us    |      }                                                      
 3)   0.275 us    |      _spin_lock();                                          
 3)   0.257 us    |      page_add_file_rmap();                                  
 3)   0.233 us    |      native_set_pte_at();                                   
 3)               |      _spin_unlock() {                                       
 3)   0.248 us    |        test_ti_thread_flag();                               
 3)   0.742 us    |      }                                                      
 3)               |      unlock_page() {                                        
 3)   0.243 us    |        page_waitqueue();                                    
 3)   0.237 us    |        __wake_up_bit();                                     
 3)   1.209 us    |      }                                                      
 3)   6.274 us    |    }                                                        
 3)   8.806 us    |  } 

Say we found:

trace_graph_entry -- handle_mm_fault()
trace_func_arg -- address:0xffffffff
trace_func_arg -- write_access:1

We'd render:

 3)               |  handle_mm_fault(.address=0xffffffff, .write_access=1) {

trace_graph_return -- handle_mm_fault()
trace_func_ret -- 2

We'd render:

 3)   8.806 us    |  } = 2

Then we can register with tracepoints inside functions to add these
generic trace_func_arg/_ret entries to augment the graph (and or
function) tracer.


Does that make sense?

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