Re: nfs.proc.open results in a kernel string copy fault

[David Smith <dsmith at redhat dot com>]

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)