RE: [patch] x86_64 specific function return probes

["Lynch, Rusty" <rusty.lynch@intel.com>]

From: Andi Kleen [mailto:ak@suse.de]
>Sent: Friday, June 03, 2005 9:46 AM
>To: Lynch, Rusty
>Cc: Andi Kleen; akpm@osdl.org; linux-kernel@vger.kernel.org; Vara
Prasad;
>Hien Nguyen; Prasanna S Panchamukhi; Jim Keniston
>Subject: Re: [patch] x86_64 specific function return probes
>
>On Fri, Jun 03, 2005 at 09:40:26AM -0700, Lynch, Rusty wrote:
>> From: Andi Kleen [mailto:ak@suse.de]
>> >On Thu, Jun 02, 2005 at 01:58:50PM -0700, Rusty Lynch wrote:
>> >> The following patch adds the x86_64 architecture specific
>> implementation
>> >
>> >[....]
>> >
>> >Thanks for the long description.
>> >
>> >but...
>> >
>> >> +struct task_struct  *arch_get_kprobe_task(void *ptr)
>> >> +{
>> >> +	return ((struct thread_info *) (((unsigned long) ptr) &
>> >> +					(~(THREAD_SIZE -1))))->task;
>> >> +}
>> >
>> >and
>> >
>> >
>> >> +	tsk = arch_get_kprobe_task(sara);
>> >
>> >
>> >This is still wrong when the code is not executing on the process
>> >stack, but on a interrupt/Exception stack. Any reason you cannot
>> >just use current here?
>> >
>> >-Andi
>>
>> Ah... you are talking about if someone registers a return probe on
>> something like an interrupt handler, right?
>
>Yes.
>
>>
>> I was under the impression that I could not always count on the
current
>> I get from interrupt context to map to the current seen by the target
>> function (that triggers the breakpoint.)  It sounds like an invalid
>> assumption lead to some extra complexity that isn't correct for all
>> cases.
>
>
>It is an invalid assumption, current works in all contexts. Except
>if your GS is broken, but that should only happen when the kernel
>is already very crashed.
>
>-Andi

Ok, let be redo this patch and take another look at the return probe
design coming down from kernel/kprobes.c

    --rusty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/