Re: Invalid filename/mode in openat tracepoint data


Hello Tristan!

That is the same path I found when debugging with strace! I think I also saw a missing comm string during my tests (with printk from BCC), but I would have to reproduce it again to be sure.

I'm going to test this one more time on kernel 4.18, as I don't remember finding this problem when I started writing the library on Ubuntu 18.10 (and maybe I'll also try to take a look at the openat implementation).

Thanks so much for your help!

Alessandro Gario

On Fri, Jul 24, 2020 at 10:11 am, Tristan Mayfield <mayfieldtristan@...> wrote:
I figured out that it's non-deterministic. So sometimes certain commands (git, awk, rm, uname, etc.) will have an openat with no filename, but other times they will.
I ran these commands experimentally and got results similar to what I have below for all of them:
$ rm something
sys_enter_openat comm: rm pid:3512 filename:/etc/ (140398792747904)
sys_enter_openat comm: rm pid:3512 filename:/lib/x86_64-linux-gnu/ (140398792789520)
sys_enter_openat comm: rm pid:3512 filename:/usr/lib/locale/locale-archive (140398792339408)
sys_enter_openat comm: rm pid:3514 filename:/etc/ (139648615484288)
sys_enter_openat comm: rm pid:3514 filename:/lib/x86_64-linux-gnu/ (139648615525904)
sys_enter_openat comm: rm pid:3514 filename: (139648615075792)
Because it's been so consistent, I believe the missing file is... always? Most of the time? At least a good part of the time "/usr/lib/locale/locale-archive".
I'm not sure why an archive file would behave differently, but it seems to be causing this issue. You can use the below bpftrace script to figure out which commands most often create the no-name situation.
if( str(args->filename) == "") {
printf("sys_enter_openat comm: %s pid:%d filename:%s (%ld)\n",comm,pid, str(args->filename), args->filename);

Join to automatically receive all group messages.