This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: nfs.proc.open results in a kernel string copy fault
- From: David Smith <dsmith at redhat dot com>
- To: Michael Obster <michael at obster dot org>
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 17 Jan 2007 09:45:08 -0600
- Subject: Re: nfs.proc.open results in a kernel string copy fault
- References: <20070117144858.srk31g1cm8go0s8w@ssl.spitfire-media.de>
Michael Obster wrote:
Hi,
perhaps someone can give me a hint. First of all I tried also the
snapshot 20070113 which did a complete system hang up. Using now the old
20061223 snapshot.
When I'm trying to use a
probe nfs.proc.open {
if (execname() != "staprun")
printf("%s: %s (%s) = ", execname(), name, argstr)
}
this results in a
ERROR: kernel string copy fault at 0x000081a4 near identifier '$filp' at
/opt/systemtap/share/systemtap/tapset/nfs_proc.stp:1223:27
when the insmod is executed.
As I have seen, there is a change in this file (snapshot 20070113). But
using the new snapshots hangs my system. Because I have no console, I
don't see whether the kernel gives me an Oops.
The kernel we are using here is not a standard kernel. It is a special
patched MontaVista Linux kernel with some additional patches for
perfctr. The version is 2.6.10 with a backport patch from 2.6.13 for the
kprobes interface compiled with gcc 3.4.3.
So I would be pleased for any hint!
Michael,
I'm unsure of how to help you. I tried your script using CVS systemtap
on RHEL4 x86_64 (2.6.9-42.0.3.EL) and beta RHEL5 x86 (2.6.18-1.2747.el5)
and it worked on both (especially after adding a '\n' to the printf
statement).
The only reference to '$filp' in probe nfs.proc.open is the following:
filename = __file_filename($filp)
The __file_filename function is defined in tapset/vfs.stp, and it looks
reasonable to me.
I might start debugging this by creating your own copy of nfs.proc.open
without the $filp reference and see if that works for you. If that
works, I'd try looking at each pointer __file_filename has to
dereference (file->f_dentry->d_name.name) and see if they make sense.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)