Re: [EXTERNAL] Re: Git clone fails in p9 file system marked with FANOTIFY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux