[Bug tapsets/16541] New: nfsd tapset has errors

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16541

            Bug ID: 16541
           Summary: nfsd tapset has errors
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

On newer kernels, the nfsd tapset has errors. This tapset gets tested by the
buildok.exp testcase, but since the test gets kfail'ed, these errors have gone
unnoticed.

Looking at the output of the following command, there are 2 classes of errors:

# stap -v -p4 src/testsuite/buildok/nfsd-detailed.stp 

1) nfsd.close error accessing $filp.

====
semantic error: not accessible at this address [man error::dwarf] (0x18707,
dieoffset: 0x5a932): identifier '$filp' at :1100:29
        source:     filename = __file_filename($filp)
====

The first thing to do is see what parameters (if any) stap can see for that
function:

# stap -L 'module("nfsd").function("nfsd_close").*'
module("nfsd").function("nfsd_close@fs/nfsd/vfs.c:856").call $filp:struct file*
module("nfsd").function("nfsd_close@fs/nfsd/vfs.c:856").exported $filp:struct
file*
module("nfsd").function("nfsd_close@fs/nfsd/vfs.c:856").inline
module("nfsd").function("nfsd_close@fs/nfsd/vfs.c:856").return $filp:struct
file*

So, stap can see $filp except for the inlined version, which isn't too
surprising since gcc typically generates poor debuginfo for inlined functions.

The solution here is to use the '.call' version on the probe points. This will
ensure that stap can find $filp and 'nfsd.close' probe hits will match more
closely with 'nfsd.close.return' probe hits.

2) Problems accessing cr_uid/cr_gid

====
semantic error: 'struct {...}' is being accessed instead of a member:
identifier '$rqstp' at /usr/local/share/systemtap/tapset/linux/nfsd.stp:233:8
        source:     uid = $rqstp->rq_cred->cr_uid
====

This is happening because this kernel has CONFIG_UIDGID_STRICT_TYPE_CHECKS on,
and uid/gid fields are simple integers anymore, but structures.

-- 
You are receiving this mail because:
You are the assignee for the bug.