[Bug tapsets/26666] New: nfsd tapset - fh_export and fh_dentry always NULL for NFSv3

[Bug tapsets/26666] New: nfsd tapset - fh_export and fh_dentry always NULL for NFSv3

[m.j.harvey at imperial dot ac.uk]

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

            Bug ID: 26666
           Summary: nfsd tapset - fh_export and fh_dentry always NULL for
                    NFSv3
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: m.j.harvey at imperial dot ac.uk
  Target Milestone: ---

Hi,

When using the nfsd.proc.entries probes, fh->fh_dentry and fh->fh_export are
always NULL when the NFS version is 3. This makes it impossible to resolve the
full path of a file. When the NFS version is 4, this members are set as
expected and task_dentry_path(), inode_path() work as expected.

To reproduce:

Set up an NFS export, mount it as nfsv3
On the server run stap --all-modules
share/systemtap/examples/network/nfsd-trace.stp 
On the client touch a new file on the mount
Onthe server note stap abort with
ERROR: read fault [man error::fault] at 0x38 near operator '->' at
nfsd-trace.stp:18:31

Remount with nfsv4, and repeat. Observe that the tap reports accesses
correctly.

adding printf("%s %s", fh->fh_dentry, fh->fh_export) and repeating confirms the
difference.

Tested on RHEL 7.8 x86-64, kernel 3.10.0-1127.19.1, with RHEL systemtap 4.0 and
also current  git head (747902ed).

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

[Bug tapsets/26666] nfsd tapset - fh_export and fh_dentry always NULL for NFSv3

[m.j.harvey at imperial dot ac.uk]

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

--- Comment #1 from MJH <m.j.harvey at imperial dot ac.uk> ---
It's not a systemtap bug, per se. The examples will never have worked with
nfsv3.

To get the filename of an access, trap the return of nfds.fh_verify, eg

probe module("nfsd").function("fh_verify").return {
 printf("%s\n", inode_path( $fhp->fh_dentry->d_inode ) )
}

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

[Bug tapsets/26666] nfsd tapset - fh_export and fh_dentry always NULL for NFSv3

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
Do you think we should extend the example, or make a nfsd3_watch.stp sample?

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

[Bug tapsets/26666] nfsd tapset - fh_export and fh_dentry always NULL for NFSv3

[m.j.harvey at imperial dot ac.uk]

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

--- Comment #3 from MJH <m.j.harvey at imperial dot ac.uk> ---
(In reply to Frank Ch. Eigler from comment #2)
> Do you think we should extend the example, or make a nfsd3_watch.stp sample?

 I'd be inclined to make a separate one, maybe renaming the others nfs4*.

The probe I peosted earlier relied on a return probe being able to access final
values of an argument. This worked on my test machine but not in our production
environment, and I understand the former is not intended behaviour. So, here's
what we are using now:


global ip
global pf
global uid

probe module("nfsd").function("nfsd3_proc_*") {
    ip[tid()] = addr_from_rqst_str($rqstp)
    pf[tid()] = probefunc()
    uid[tid()] = $rqstp->rq_cred->cr_uid->val
}

probe module("nfsd").function("nfsd_permission") {
    printf("%d %s %s : %s\n", uid[tid()], pf[tid()], ip[tid()], inode_path(
$dentry->d_inode ) )
}

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