Hi Amir, Yes, and my guess is that the MDE software running on your machine had reacted fanotify_read() error as a threat and removed the .config file, that is why it could not be found by the open syscall?? >>>>No, that can't be because I have performed the exercises by uninstalling MDE software running in WSL(5.15 and 6.3). Git clone succeeds, but the listener terminates as you see in your machine in standard linux. It is the same manifestation. In MDE software, Fanotify marking was just being done only with CLOSE_WRITE in mask, while the example code(fanotify listener) was having mask OPEN_PERM | CLOSE_WRITE. I shall include OPEN_PERM in the mask in MDE and then invoke git clone and then see if it succeeds. Can you explain the significance of OPEN_PERM and its relation with CLOSE_WRITE ? Thank you, Krishna Vivek -----Original Message----- From: Amir Goldstein <amir73il@xxxxxxxxx> Sent: Thursday, September 26, 2024 2:52 PM To: Krishna Vivek Vitta <kvitta@xxxxxxxxxxxxx> Cc: Jan Kara <jack@xxxxxxx>; linux-fsdevel@xxxxxxxxxxxxxxx; Eric Van Hensbergen <ericvh@xxxxxxxxxx>; Latchesar Ionkov <lucho@xxxxxxxxxx>; Dominique Martinet <asmadeus@xxxxxxxxxxxxx>; v9fs@xxxxxxxxxxxxxxx Subject: Re: [EXTERNAL] Re: Git clone fails in p9 file system marked with FANOTIFY On Thu, Sep 26, 2024 at 9:44 AM Krishna Vivek Vitta <kvitta@xxxxxxxxxxxxx> wrote: > > Hi Amir > > Thanks for the outputs. From your analysis, it is found that there are some dentry references that are causing issues in p9 to report ENOENT error. Yes, and my guess is that the MDE software running on your machine had reacted fanotify_read() error as a threat and removed the .config file, that is why it could not be found by the open syscall?? > > Few questions: > 1.) What is the kernel version of your setup ? Latest upstream master. > 2.) Is there any command/tool to check the marked mount points ? > Yes and no. No "tool" that I know of, but the information is usually available. There is a way to list all the fanotify group fds of a process or processes: root@kvm-xfstests:~# ls -l /proc/*/fd/* 2>/dev/null |grep fanotify lrwx------ 1 root root 64 Sep 26 09:02 /proc/1928/fd/3 -> anon_inode:[fanotify] and there is a way to list the marks set by this group: root@kvm-xfstests:~# cat /proc/1928/fdinfo/3 pos: 0 flags: 02004002 mnt_id: 16 ino: 2058 fanotify flags:7 event-flags:8000 fanotify mnt_id:58 mflags:0 mask:40010008 ignored_mask:0 mnt_id is in hex (0x58), so it needs to be translated to mount point like this: root@kvm-xfstests:~# cat /proc/self/mountinfo |grep ^$((0x58)) 88 21 0:34 / /vtmp rw,relatime shared:46 - 9p v_tmp rw,access=client,msize=262144,trans=virtio For inode and super_block marks, the identifier is the st_dev (also in hex) so some more conversions are needed to map it to device number as 0:34. lsof does come to mind as a tool that could be enhanced to provide this information, but perhaps a specialized fsnotify tool is in order. I created https://github.com/amir73il/fsnotify-utils a long time ago with the intention of writing some useful tools, but that never happened... > What would be the next steps for this investigation ? > I need to find some time and to debug the reason for 9p open failure so we can make sure the problem is in 9p code and report more details of the bug to 9p maintainers, but since a simple reproducer exists, they can also try to reproduce the issue right now. Thanks, Amir.
