Bug 2185

Summary:	Support reentrance from post handler on x86_64
Product:	systemtap	Reporter:	Anil S Keshavamurthy <anil.s.keshavamurthy>
Component:	kprobes	Assignee:	Anil S Keshavamurthy <anil.s.keshavamurthy>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Attachments:	disarming kprobe not required since DEBUG_STATCK supports reentrancy

Description Anil S Keshavamurthy 2006-01-20 00:48:03 UTC

Currently kprobes on x86_64, in case of reentrance from post handler
disarm's the probe itself to avoid debug stack corruption and system crash.

However I saw this mail form Andi Kleen on discuss x86_64 mailing list on Mon, 
16 Jan 2006 01:56:39 +0100 
( http://www.x86-64.org/lists/discuss/msg08165.html ) which now
allows nesting of the debug entry point too. So I guess now it should be 
possible for us to support reentrancy from post handler on x86_64. (Worth a 
try, so opening this bug)

The above patch from Andi also unbreaks recursive kprobes from post handler 
which got broken starting from 2.6.15-git12.

Comment 1 Anil S Keshavamurthy 2006-03-17 22:10:59 UTC

Created attachment 931 [details]
disarming kprobe not required since DEBUG_STATCK supports reentrancy

Any testing of this patch is appreciated.

Comment 2 Masami Hiramatsu 2008-07-30 17:15:38 UTC

As far as I read below thread, this problem still might exist on x86-64.
http://www.x86-64.org/pipermail/discuss/2006-March/008113.html

Comment 3 Przemysław Pawełczyk 2010-08-16 21:41:07 UTC

    Since v2.6.33-rc1 following commit is in the mainline:

commit f5ad31158d60946b9fd18c8a79c283a6bc432430
Author: Masami Hiramatsu <mhiramat@redhat.com>
Date:   Thu Aug 27 13:23:04 2009 -0400

    kprobes/x86-64: Allow to reenter probe on post_handler
    
    Allow to reenter probe on the post_handler of another probe on x86-64,
    because x86-64 already allows reentering int3.
    In that case, reentered probe just increases kp.nmissed and returns.

Comment 4 Frank Ch. Eigler 2010-08-16 21:46:16 UTC

kernel appears to be fixed