Jim Keniston | 1 Dec 01:14 2005
Picon

12/1 SystemTap conf call agenda

Suggested topics for tomorrow's conf call:
- Review of ARs from 11/15-16/05 meeting:
http://sourceware.org/ml/systemtap/2005-q4/msg00253.html
- Review of any key/blocking bugs
- Monitoring LKML for opportunities to help using SystemTap

Jim

Zhang, Yanmin | 1 Dec 01:47 2005
Picon

RE: jprobe question

>>-----Original Message-----
>>From: Keshavamurthy, Anil S
>>Sent: 2005年12月1日 4:56
>>To: Zhang, Yanmin
>>Cc: 'systemtap <at> sources.redhat.com'; Mao, Bibo
>>Subject: RE: jprobe question
>>
>>>Here are the patches. In function non_syscall, I save the
>>>ar.bsp (after instruction cover) to the scratch area below
>>>pt_regs, then calls preserve_scratch_area.
>>>preserve_scratch_area will reserve 1 new 16-byte area for next
>>>call to ia64_bad_break. Later on, kprobe handler uses
>>>pt_regs->cr_ifs and the saved ar.bsp to get the real ar.bsp
>>>and parameter number. This approach also considers user space
>>>probe. kprobe_save_bsp patch has no any impact on critical fault patch.
>>>The jprobe patch is to save the function parameters when the
>>>jprobe is hit and restore them after break.
>>
>>Yanmin,
>>	I am not sure whether using the scratch area below the pt_regs
>>to save ar.bsp would be the right thing to do and more over it does look like
>>a hack.
>>Clean solution would be to have a field in pt_regs to save ar.bsp,
[YM] Yes. But some bigwigs might be unhappy to add new members into pt_regs.

 until we
>>have it, here is what you can do for now.
>>
>>In the setjmp_pre_handler() get the ar.bsp by unwinding the stack
>>and then calling unw_get_bsp() to get the ar.bsp. Save this ar.bsp in the kcb
(Continue reading)

Keshavamurthy, Anil S | 1 Dec 02:39 2005
Picon

RE: jprobe question

>[YM] unwind costs too much time because it will create a 
>switch_stack and unwind frame on the top of the stack. Anyway, 
>I will work out a new patch using unwind.

Yes, I understand the unwind cost, but at the 
same time hate quick and dirty way to store bsp 
in the pt_reg reserved area. For now don't
worry about the unwind cost. Let's 
push saving bsp patch separately later and at
that time we can optimize jprobes.

Also more comment before you cook up the new patch, 
some people on ia64 mailing list don't like adding 
asm volatile ("....") instruction in the C file.
If possible avoid this asm in the C file.

Post your new patch onto Ia64 mailing list and Cc'ing systemtap.

-Anil

Zhang, Yanmin | 1 Dec 03:28 2005
Picon

[PATCH] save parameter registers and restore them for jprobe handling

When jprobe is hit, the function parameters of the original function
should be saved before jprobe handler is executed, and restored it after
jprobe handler is executed, because jprobe handler might change the
register values.

Here is a patch against 2.6.14-mm1.

Signed-off-by: Zhang Yanmin <yanmin.zhang <at> intel.com>

Attachment (jprobe_protect_out_reg_ia64_v2.patch): application/octet-stream, 4203 bytes
Keith Owens | 1 Dec 03:37 2005
Picon

Re: [PATCH] save parameter registers and restore them for jprobe handling

On Thu, 1 Dec 2005 10:28:09 +0800, 
"Zhang, Yanmin" <yanmin.zhang <at> intel.com> wrote:
>Content-Transfer-Encoding: base64

Why base64 encoding for the patch?

+/*Invalidate stacked registers outside the current frame*/
+#define invalidate_stacked_regs() { 				\
+	unsigned long rsc_save = 0;				\
+	asm volatile("mov %0=ar.rsc;;\n\t"			\
+		"mov ar.rsc=0;;\n\t"				\
+		"{\n\tloadrs;;\n\t\n\t\n\t}\n\t"		\
+		"mov ar.rsc=%1\n\t"				\
+		:"=r" (rsc_save):"r" (rsc_save):"memory");	\
+	}
+

We try to avoid inline asm in the .c files, it makes it harder to
compile the kernel with Intel compilers.

Mao, Bibo | 1 Dec 04:32 2005
Picon

[BUG][PATCH] Kprobes: Reference count the modules when probed on it

When a Kprobes are inserted/removed on a modules,
the modules must be ref counted so as
not to allow to unload while probes are registered
on that module.

Without this patch, the probed module is free to unload,
and when the probing module unregister the probe, the
kpobes code while trying to replace the original instruction
might crash.

Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy <at> intel.com>
Signed-off-by: Mao Bibo <bibo.mao <at> intel.com>

 kernel/kprobes.c |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

Index: linux-2.6.15-rc3/kernel/kprobes.c
===================================================================
--- linux-2.6.15-rc3.orig/kernel/kprobes.c
+++ linux-2.6.15-rc3/kernel/kprobes.c
 <at>  <at>  -462,9 +462,16  <at>  <at>  int __kprobes register_kprobe(struct kpr
 	int ret = 0;
 	unsigned long flags = 0;
 	struct kprobe *old_p;
+	struct module *mod;
+
+	if ((!kernel_text_address((unsigned long) p->addr)) ||
+		in_kprobes_functions((unsigned long) p->addr))
+		return -EINVAL;
+
(Continue reading)

Zhang, Yanmin | 1 Dec 06:19 2005
Picon

RE: [PATCH] save parameter registers and restore them for jprobe handling

>>-----Original Message-----
>>From: linux-ia64-owner <at> vger.kernel.org
>>[mailto:linux-ia64-owner <at> vger.kernel.org] On Behalf Of Keith Owens
>>Sent: 2005年12月1日 10:37
>>To: Zhang, Yanmin
>>Cc: linux-ia64 <at> vger.kernel.org; Keshavamurthy, Anil S;
>>systemtap <at> sources.redhat.com
>>Subject: Re: [PATCH] save parameter registers and restore them for jprobe
>>handling
>>
>>On Thu, 1 Dec 2005 10:28:09 +0800,
>>"Zhang, Yanmin" <yanmin.zhang <at> intel.com> wrote:
>>>Content-Transfer-Encoding: base64
>>
>>Why base64 encoding for the patch?
>>
>>+/*Invalidate stacked registers outside the current frame*/
>>+#define invalidate_stacked_regs() { 				\
>>+	unsigned long rsc_save = 0;				\
>>+	asm volatile("mov %0=ar.rsc;;\n\t"			\
>>+		"mov ar.rsc=0;;\n\t"				\
>>+		"{\n\tloadrs;;\n\t\n\t\n\t}\n\t"		\
>>+		"mov ar.rsc=%1\n\t"				\
>>+		:"=r" (rsc_save):"r" (rsc_save):"memory");	\
>>+	}
>>+
>>
>>We try to avoid inline asm in the .c files, it makes it harder to
>>compile the kernel with Intel compilers.

(Continue reading)

Guanglei Li | 1 Dec 10:28 2005
Picon

relocation refers to undefined symbol

Hi,

Today I tried to add probe points to some functions in modules, ex:

probe module("scsi_mod").function("scsi_dispatch_cmd")
{
   log("here")
}

but stap will give the error:

root:/root>stap a.stp
WARNING: cannot find module scsi_mod debuginfo: relocation refers to 
undefined symbol
semantic error: no match for probe point
         while: resolving probe point 
module("scsi_mod").function("scsi_dispatch_cmd")
Pass 2: analysis failed.  Try again with '-v' (verbose) option.

I tried to probe module("sd_mod").function("*"), it succeed.

But when tried to probe module("ext3").function("*"), I got the same 
error.

After looked into the systemTap src, I found this error was generated 
by calling __libdwfl_relocate:

Breakpoint 4, load_dw (mod=0x9aeff90, debugfile=0x9aeffc4) at 
dwfl_module_getdwarf.c:306
306     result = __libdwfl_relocate (mod, debugfile->elf);
(Continue reading)

Guanglei Li | 1 Dec 10:35 2005
Picon

Re: relocation refers to undefined symbol


> 306     result = __libdwfl_relocate (mod, debugfile->elf);
> (gdb) p result
> $72 = DWFL_E_NOERROR
sorry, it should be DWFL_E_RELUNDEF
> (gdb) p *debugfile

William Cohen | 1 Dec 18:35 2005
Picon

Comments about implementing kprobes with Xen paravirtualization kernels

Talked with Stephen Tweedie about kprobes in Xen. Right now kprobes is
disable in the Xen configuration because it doesn't work. Appearently
there are things that build in Xen, but do not work. The current
approach in Xen copies large chunks of code of specific architectures
into Xen, then changes are made on the code. This leads to a maintence
headaches. Having to copy patches over to Xen code and then modify
them because of the additional Xen changes.  This is one of the things
that needs to changes before Xen is accepted in the mainline Linux
kernel.

There are patches being generated for the FC5 kernel by taking
differences between the linus-2.6 (kernel.org) and merge-2.6
(xensource) kernels. These patches do not aways work because of the
additional patches we have on FC5, e.g. VSDO builds in FC5 xen kernels
but do not boot.

Need a list of all the patches used to implement kprobes in the
kernel. For this the related xen arch files could be generated and
this could be used as a starting point. Otherwise it is going to be
painful manual process to create the equivalent kprobes patch for Xen.
However, once there is a patch, Stephen thought it was quite likely
that the xensource people would be willing to accept it.

One open question was whether Xen allows the text of the kernel to be
modified.

-Will


Gmane