linux-kernel - Re: [PATCH] markers-linker-generic

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <461D7BA5.4050009@us.ibm.com>
Date:	Wed, 11 Apr 2007 17:21:57 -0700
From:	Vara Prasad <prasadav@...ibm.com>
To:	Jim Keniston <jkenisto@...ibm.com>
CC:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Russell King <rmk@....linux.org.uk>,
	"Frank Ch. Eigler" <fche@...hat.com>, systemtap@...rces.redhat.com
Subject: Re: [PATCH] markers-linker-generic

Jim Keniston wrote:

>On Wed, 2007-04-11 at 15:21 -0400, Mathieu Desnoyers wrote:
>  
>
>>* Andrew Morton (akpm@...ux-foundation.org) wrote:
>>    
>>
>>>On Wed, 11 Apr 2007 13:51:11 -0400
>>>Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
>>>
>>>      
>>>
>>>>>What's this marker stuff about?
>>>>>
>>>>>          
>>>>>
>>>>Hi Russel,
>>>>
>>>>Here is an overview :
>>>>        
>>>>
>>>I am told that the systemtap developers plan to (or are) using this
>>>infrastructure.
>>>
>>>      
>>>
>>Quoting Frank Ch. Eigler, from the SystemTAP team :
>>
>>"The LTTng user-space programs use it today.  Systemtap used to support
>>the earlier marker prototype and will be rapidly ported over to this
>>new API upon acceptance."
>>
>>
>>    
>>
>>>If correct: what is their reason for preferring it over kprobes?
>>>      
>>>
Markers are not a substitute or preference over kprobes, they augment 
kprobes by enabling additional functionality.

>>>      
>>>
>>I will let them answer on this one..
>>
>>    
>>
>
>I'll take a shot at this one.
>
>First of all, kprobes remains a vital foundation for SystemTap.  But
>markers are attactive as an alternate source of trace/debug info.
>Here's why:
>
>1. Markers will live in the kernel and presumably be kept up to date by
>the maintainers of the enclosing code.  We have a growing set of tapsets
>(probe libraries), each of which "knows" the source code for a certain
>area of the kernel.  Whenever the underlying kernel code changes (e.g.,
>a function or one of its args disappears or is renamed), there's a
>chance that the tapset will become invalid until we bring it back in
>sync with the kernel.  As you can imagine, maintaining tapsets separate
>from the kernel source is a maintenance headache.  Markers could
>mitigate this.
>  
>
Jim's above stated reason is not a consideration for markers. We don't 
plan to convert the current tapsets to use markers. We do need to 
augment tapsets with a few markers in the kernel code where it is not 
easy to put a kprobe in a maintainable fashion -- e.g in the middle of a 
function.

>2. Because the kernel code is highly optimized, the kernel's dwarf info
>doesn't always accurately reflect which variables have which values on
>which lines (sometimes even upon entry to a function).  A marker is a
>way to ensure that values of interest are available to SystemTap at
>marked points.
>  
>
Agreed

>3. Sometimes the overhead of a kprobe probepoint is too much (either in
>terms of time or locking) for the particular hotspot we want to probe.
>
>  
>
Agreed

>Jim
>
>  
>
bye,
Vara Prasad

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