linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Feb 2009 09:39:02 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [rfd] function-graph augmentation


* Peter Zijlstra <peterz@...radead.org> wrote:

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

Yeah, it looks really nice that way.

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