headers
Masami Hiramatsu | 1 Mar 2006 05:40
Picon

[PATCH] kprobe: kprobe-booster fix for NX support on i386

Hi, Andrew

Here is the patch to fix kprobe-booster against linux-2.6.16-rc5-mm1.
 - Fix to assign the correct address of the instruction buffer.
   From linux-2.6.16-rc5, the ainsn.insn on i386 arch became a pointer
   instead of an array itself.

Best regards,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu <at> sdl.hitachi.co.jp

Signed-off-by: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>

 kprobes.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)
diff -Narup a/arch/i386/kernel/kprobes.c b/arch/i386/kernel/kprobes.c
--- a/arch/i386/kernel/kprobes.c	2006-03-01 09:53:22.000000000 +0900
+++ b/arch/i386/kernel/kprobes.c	2006-03-01 09:56:58.000000000 +0900
 <at>  <at>  -313,7 +313,7  <at>  <at>  static int __kprobes kprobe_handler(stru
 	    !p->post_handler && !p->break_handler ) {
 		/* Boost up -- we can execute copied instructions directly */
 		reset_current_kprobe();
-		regs->eip = (unsigned long)&p->ainsn.insn;
+		regs->eip = (unsigned long)p->ainsn.insn;
 		preempt_enable_no_resched();
 		return 1;
(Continue reading)

Permalink | Reply | 0 comments |
headers
guanglei at cn dot ibm dot com | 1 Mar 2006 15:41
Favicon

[Bug kprobes/2387] system crash on ppc64/2.6.15.4


------- Additional Comments From guanglei at cn dot ibm dot com  2006-03-01 14:41 -------
I tried the 2.6.15.1-2.6.15.4 and 2.6.16-rc5 kernels, and all of them gave
almost the same error like:
Unable to handle kernel paging request for data at address ...

And if I don't use -b option of systemtap, it seemed that it could run for a
long time without kernel panic.

And I also noticed that the kernel reported the I/O error even when I wasn't
running systemtap and only did some simple writing operations:
end_request: I/O error, dev sda, sector 17445
end_request: I/O error, dev sda, sector 17447
end_request: I/O error, dev sda, sector 17449
Aborting journal on device sda2.
ext3_abort called.
EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only

The same version of systemtap could run very well with 2.6.9-30EL, so it is a
bug of the mainline kernel.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=2387

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prasanna S Panchamukhi | 1 Mar 2006 15:50
Picon

Re: [PATCH] Kprobes- robust fault handling for i386

On Tue, Feb 28, 2006 at 12:25:26PM -0800, Keshavamurthy Anil S wrote:
> On Tue, Feb 28, 2006 at 06:38:36AM -0800, Prasanna S Panchamukhi wrote:
> > 
> >    Anil,
> > 
> >    Thanks for your review comments. Please see the updated patch
> >    below, this patch is only for i386 architecture and once
> >    we are ok with it, we will port it to other architectures.
> This version looks good with no new Kprobes states.
> Makes life easy to understand :-)
> 
> >    [..]The main reason to avoid post_handler execution in this
> >    case is to avoid any incosistant data references between pre and post
> >    handlers.
> Okay, I got that point, but if the fault recovery in pre_handler
> is *successful*, then in this case you *should* permit calling
> post_handler. See my inline comments to address this issue.

Anil,

To skip post_handler execution for unsuccessful fault recovery in the
pre_hanlder, we need to take several things like aggrigate kprobe
handlers, using the same kprobe structures across the same probe hit on 
different cpus at the same time etc. This restricts us from avoiding
execution of the post-handler in case of unsuccessful fault recovery.
Please find the patch below that allows post-handler execution in all
cases as of now.

Thanks
Prasanna
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ch. Eigler | 1 Mar 2006 16:38
Picon
Favicon
Gravatar

Re: [Bug kprobes/2387] system crash on ppc64/2.6.15.4


guanglei <at> cn.ibm.com wrote:

> [...]
> And I also noticed that the kernel reported the I/O error even when I wasn't
> running systemtap and only did some simple writing operations:
> [...]
> end_request: I/O error, dev sda, sector 17449
> Aborting journal on device sda2.
> ext3_abort called.
> EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal
> Remounting filesystem read-only

If this appears without having run systemtap, you almost certainly
have a problem with your hardware.  Boot it single-user, run fsck -c.

- FChE
Permalink | Reply | 0 comments |
headers
jrs at us dot ibm dot com | 1 Mar 2006 17:25
Favicon

[Bug kprobes/2387] system crash on ppc64/2.6.15.4


------- Additional Comments From jrs at us dot ibm dot com  2006-03-01 16:25 -------
If you are seen problem even when not using SystemTap the this is probably
something outside of SystemTap.  I suggest following this up on the linux-kernel
and linuxppc64-dev mailing list to see if the problems is located in the kernel.

We should mark this bug as rejected until its proven that it is a SystemTap problem.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=2387

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
guanglei at cn dot ibm dot com | 1 Mar 2006 17:36
Favicon

[Bug kprobes/2387] system crash on ppc64/2.6.15.4


------- Additional Comments From guanglei at cn dot ibm dot com  2006-03-01 16:36 -------
(In reply to comment #4)
> If you are seen problem even when not using SystemTap the this is probably
> something outside of SystemTap.  I suggest following this up on the linux-kernel
> and linuxppc64-dev mailing list to see if the problems is located in the kernel.
> 
> We should mark this bug as rejected until its proven that it is a SystemTap
problem.

the error : end_request: I/O error, dev sda, sector 17445 ...
will happen without running systemtap. It will occur after I copied something
into that partition. But I am not sure if it is the reason of causing kernel
panic when running systemtap.

The error:
Unable to handle kernel paging request for data at address
will happed when running stap with -b option.
But I agree with Jose that it may not be a systemtap bug, because systemtap
could work quite well on the redhat shipped kernels(2.6.9-30.EL, 2.6.9-27.EL).

It should not be a hardware failure because I tried it on different machines,
and even after reformat the partition. all of them have the same error.

The 2.6.15 kernel has some changes about power arch(move ppc64 to powerpc
directory), and the relayfs diffs a lot from RH shipped kernel. I tried not to
compile relayfs in 2.6.15* and want systemtap compile it, but failed. the
relayfs shipped with systemtap can't be compiled. some function signatures has
changed, and if I have time I'll try to replace relayfs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
zanussi at us dot ibm dot com | 1 Mar 2006 17:56
Favicon

[Bug kprobes/2387] system crash on ppc64/2.6.15.4


------- Additional Comments From zanussi at us dot ibm dot com  2006-03-01 16:56 -------
(In reply to comment #5)
> (In reply to comment #4)
> > If you are seen problem even when not using SystemTap the this is probably
> > something outside of SystemTap.  I suggest following this up on the linux-kernel
> > and linuxppc64-dev mailing list to see if the problems is located in the kernel.
> > 
> > We should mark this bug as rejected until its proven that it is a SystemTap
> problem.
> 
> the error : end_request: I/O error, dev sda, sector 17445 ...
> will happen without running systemtap. It will occur after I copied something
> into that partition. But I am not sure if it is the reason of causing kernel
> panic when running systemtap.
> 
> The error:
> Unable to handle kernel paging request for data at address
> will happed when running stap with -b option.
> But I agree with Jose that it may not be a systemtap bug, because systemtap
> could work quite well on the redhat shipped kernels(2.6.9-30.EL, 2.6.9-27.EL).
> 
> It should not be a hardware failure because I tried it on different machines,
> and even after reformat the partition. all of them have the same error.
> 
> The 2.6.15 kernel has some changes about power arch(move ppc64 to powerpc
> directory), and the relayfs diffs a lot from RH shipped kernel. I tried not to
> compile relayfs in 2.6.15* and want systemtap compile it, but failed. the
> relayfs shipped with systemtap can't be compiled. some function signatures has
> changed, and if I have time I'll try to replace relayfs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Hunt | 1 Mar 2006 19:31
Picon
Favicon

syscall tapset reorg again?

Hien,

I checked in returnstr(). So a simple probe might look like this:

probe syscall.close {
        printf("%s: %s(%s) = ", execname(), name, argstr)
}

probe syscall.close.return {
        printf("%s\n", returnstr(returnp))
}

syscalls that return pointers should set returnp to 2 in
the return probe to indicate that returnstr should display the output in
hex.

---

I think it is time to attempt a reorganization of the syscalls. Actually
we probably should have done this first. Instead of syscalls.stp,
syscalls2.stp and aux_syscalls.stp, I think we need something like
syscall_net.stp, syscall_file.stp, syscall_process.stp, syscall_ipc.stp,
and syscall_misc.stp. This makes it easier to work on related syscalls.
Plus it should speed up the translation process. We can combine the
probes with the functions they use. Or perhaps it is better to put them
in their own set of files; net_funcs.stp, file_funcs.stp, etc. These
could be useful to script writers even if not using the syscall tapset.

Martin
(Continue reading)

Permalink | Reply | 0 comments |
headers
anil dot s dot keshavamurthy at intel dot com | 1 Mar 2006 21:27
Favicon

[Bug kprobes/2408] New: [RHEL4 U4] Backport Kprobes fixes from mainline

RHEL4 U3 had the kprobes scalability patches in it and since
then we have fixed several issues in Kprobes.

The intent of this bugzilla is that the back port of these
mainline patches gets through testing and review before it
gets into RH distributions.

--

-- 
           Summary: [RHEL4 U4] Backport Kprobes fixes from mainline
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: kprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: anil dot s dot keshavamurthy at intel dot com

http://sourceware.org/bugzilla/show_bug.cgi?id=2408

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 18 comments |
headers
fche at redhat dot com | 1 Mar 2006 21:32
Favicon

[Bug kprobes/2408] [RHEL4 U4] Backport Kprobes fixes from mainline


------- Additional Comments From fche at redhat dot com  2006-03-01 20:32 -------
I recommend opening a bug on bugzilla.redhat.com against RHEL instead of this
bug here.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=2408

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |

Gmane