[Bug tapsets/17920] New: File descriptor to pathname function

[Bug tapsets/17920] New: File descriptor to pathname function

[brendan.d.gregg at gmail dot com]

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

            Bug ID: 17920
           Summary: File descriptor to pathname function
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: brendan.d.gregg at gmail dot com

FD to pathname translations are handy. Eg:

# ls -l /proc/1130/fd/1
l-wx------ 1 root root 64 Feb  3 18:21 /proc/1130/fd/1 ->
/mnt/logs/system/auth.log

I'd like a function in SystemTap that converts an integer file descriptor, for
the current process/task, to the pathname as seen by /proc/PID/fd. Without
needing kernel debuginfo (/proc/PID/fd doesn't need it).

The use case is identifying which file system files are being opened, read, and
written to. Other file descriptor types, like pipes and sockets, are less
important. I'd be fine with them returning just "[socket]" for now, or, better
still, just match what /proc already uses. Eg:

# ls -l /proc/18959/fd/3
lr-x------ 1 root root 64 Feb  3 18:20 /proc/18959/fd/3 -> socket:[181107359]

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

[Bug tapsets/17920] File descriptor to pathname function

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

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

--- Comment #1 from David Smith <dsmith at redhat dot com> ---
I looked into this today. I'm not sure it is possible to do, at least cleanly.

For reference's sake, here's what I came up with. Note that this only works on
semi-recent kernels (I developed this on rawhide -
4.3.0-0.rc2.git1.1.fc24.x86_64) and isn't correct with respect to locking data
structures. See comments for details.

====
function task_fd_lookup:long(task:long, fd:long)
%{
        struct task_struct *t = (struct task_struct *)(long)STAP_ARG_task;
        unsigned int fd = (unsigned int)(unsigned long)STAP_ARG_fd;
        struct files_struct *files = NULL;
        struct file *file = NULL;
        int put_task_struct_needed = 0;

        /* Before using the task_struct pointer, make sure it is valid
         * to read. */
        (void)kderef_buffer(NULL, t, sizeof(struct task_struct));

        get_task_struct(t);
        put_task_struct_needed = 1;

        // This is *wrong*. We should be calling get_files_struct()
        // here, but it isn't exported. This means that we can't lock
        // the files_struct. So, let's hope keeping the task_struct
        // usage count increased is enough.
        files = t->files;

        if (files) {
                /* Before using the files_struct pointer, make sure it is
                 * valid to read. */
                (void)kderef_buffer(NULL, files, sizeof(struct files_struct));

                spin_lock(&files->file_lock);
                file = fcheck_files(files, fd);
                spin_unlock(&files->file_lock);
        }

        if (file) {
                // Sigh. This is really wrong also. We're returning a
                // pointer which isn't locked or has had its usage
                // count increased. There is nothing keeping this
                // pointer valid until we use it later.
                STAP_RETURN(file);
        }
        else {
            STAP_ERROR ("cannot find file in task");
        }

        CATCH_DEREF_FAULT();
        if (put_task_struct_needed)
                put_task_struct(t);
%}

probe begin
{
    file = task_fd_lookup(task_current(), 0)
    println(fullpath_struct_path(&@cast(file, "file")->f_path))
    exit()
}
====

Note that this code doesn't handle pipes, sockets, etc., but that is the least
of the worries about the above code.

Perhaps a better way of going here would be put a probe on vfs.open, vfs.write,
and vfs.read and if you aren't in your target process skip the probe. Something
like this:

====
probe vfs.read, vfs.write
{
    if (pid() != target()) next
    printf("%s: %s\n", name, fullpath_struct_path(&file->f_path))
}

probe vfs.open
{
    if (pid() != target()) next
    printf("%s: %s\n", name, pathname)
}
====

====
# stap ./file_monitor.stp -c "/bin/ls /dev/null"
/dev/null
vfs.open: /usr/bin/ls
vfs.read: /usr/bin/ls
vfs.read: /usr/bin/ls
vfs.read: /usr/bin/ls
vfs.open: /usr/lib64/ld-2.22.90.so
vfs.read: /usr/lib64/ld-2.22.90.so
vfs.read: /usr/lib64/ld-2.22.90.so
vfs.open: /etc/ld.so.cache
vfs.open: /usr/lib64/libselinux.so.1
vfs.read: /usr/lib64/libselinux.so.1
vfs.open: /usr/lib64/libcap.so.2.24
vfs.read: /usr/lib64/libcap.so.2.24
vfs.open: /usr/lib64/libc-2.22.90.so
vfs.read: /usr/lib64/libc-2.22.90.so
vfs.open: /usr/lib64/libpcre.so.1.2.5
vfs.read: /usr/lib64/libpcre.so.1.2.5
vfs.open: /usr/lib64/libdl-2.22.90.so
vfs.read: /usr/lib64/libdl-2.22.90.so
vfs.open: /usr/lib64/libattr.so.1.1.0
vfs.read: /usr/lib64/libattr.so.1.1.0
vfs.open: /usr/lib64/libpthread-2.22.90.so
vfs.read: /usr/lib64/libpthread-2.22.90.so
vfs.open: /usr/lib/locale/locale-archive
vfs.write: /dev/pts/2
====

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

[Bug tapsets/17920] File descriptor to pathname function

[dsmith at redhat dot com]

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

--- Comment #2 from David Smith <dsmith at redhat dot com> ---
I filed bug #19021 on the tapset function task_dentry_path(), asking that it
handle more than just files. That is the place to add support for sockets and
the like.

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

[Bug tapsets/17920] File descriptor to pathname function

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
Fixed in commit 1ffc2a8. Frank convinced me that I was being too pessimistic
about my original code.

Here's an example of how you call the new task_fd_lookup() function:

====
    try {
         file = task_fd_lookup(task_current(), 5)
         printf("%d: %s\n", 5, fullpath_struct_file(task_current(), file))
    } catch {
         printf("%d: fail reading file\n", 5)
    }
====

Also bug #9021 is now fixed, so task_dentry_path() should return the correct
pathnames for synthetic filesystems, like pipes, sockets, etc.

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