Hi Amir Thanks for the reply. We have another image with kernel version: 6.6.36.3. git clone operation fails there as well. Do we need to still try with 5.15.154 kernel version ? Currently, we are marking the mount points with mask(FAN_CLOSE_WRITE) to handle only close_write events. Do we need to add any other flag in mask and check ? Following is the mount entry in /proc/mounts file: C:\134 /mnt/c 9p rw,noatime,aname=drvfs;path=C:\;uid=0;gid=0;symlinkroot=/mnt/,cache=5,access=client,msize=65536,trans=fd,rfd=4,wfd=4 0 0 Attached is the strace for failed git clone operation(line: 419, 420). Even I wrote a small program to invoke rename, followed with open. The open fails immediately and succeeds after 3-4 iterations.This exercise was performed on p9 file system marked with fanotify. Am not reporting this as regression. We havent checked this behavior before. Thank you, Krishna Vivek -----Original Message----- From: Amir Goldstein <amir73il@xxxxxxxxx> Sent: Monday, September 23, 2024 4:57 PM To: Krishna Vivek Vitta <kvitta@xxxxxxxxxxxxx> Cc: linux-fsdevel@xxxxxxxxxxxxxxx; jack@xxxxxxx Subject: [EXTERNAL] Re: Git clone fails in p9 file system marked with FANOTIFY On Sat, Sep 21, 2024 at 1:17 PM Krishna Vivek Vitta <kvitta@xxxxxxxxxxxxx> wrote: > > > Hi experts, > Hi Krishna, > Need your help in identifying the root cause for issue. > > We've seen multiple reports of git repositories failing to clone / getting corrupted in p9 file system. > The mount points under this file system are marked for FANOTIFY(flags: > FAN_MARK_ADD | FAN_MARK_MOUNT) to intercept file system events > Which events? Permission events I suppose? Which ones exactly? > When we remove the marking on these mount points, git clone succeeds. > > Following is the error message: > kvitta@DESKTOP-OOHD5UG:/mnt/c/Users/Krishna Vivek$ git clone > https://github.com/zlatko-michailov/abc.git gtest Cloning into 'gtest'... > fatal: unknown error occurred while reading the configuration files > > We have a MDE(Microsoft Defender for Endpoint) for Linux client running on the this device which marks the filesystems for FANOTIFY to listen to file system events. And, the issue(git clone failure) is occurring only in mount points of p9 file systems. > > Following is the system information > > root@DESKTOP-OOHD5UG [ ~ ]# cat /etc/os-release NAME="Common Base > Linux Mariner" > VERSION="2.0.20240609" > ID=mariner > VERSION_ID="2.0" > PRETTY_NAME="CBL-Mariner/Linux" > ANSI_COLOR="1;34" > HOME_URL=https://nam06.safelinks.protection.outlook.com/?url=https%3A%25 > 2F%2Faka.ms%2Fcbl-mariner&data=05%7C02%7Ckvitta%40microsoft.com%7C095a > 30958227462e279808dcdbc29fe2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C > 0%7C638626876223349265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hXNobev > aaTzQWhvKFkxHNvBSxyjE%2FYeVV91dWFCdJsY%3D&reserved=0 > BUG_REPORT_URL=http://htt/ > ps%3A%2F%2Faka.ms%2Fcbl-mariner&data=05%7C02%7Ckvitta%40microsoft.com% > 7C095a30958227462e279808dcdbc29fe2%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C638626876223364512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=N > FwwVFjUcm7CEgwngfi06YRMhB4LgELRP4%2FTV7Pc2%2FY%3D&reserved=0 > SUPPORT_URL=https://nam06.safelinks.protection.outlook.com/?url=https%25 > 3A%2F%2Faka.ms%2Fcbl-mariner&data=05%7C02%7Ckvitta%40microsoft.com%7C0 > 95a30958227462e279808dcdbc29fe2%7C72f988bf86f141af91ab2d7cd011db47%7C1 > %7C0%7C638626876223379110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=86GQ > 2fFjVyrpiNsddw%2Bk2a8n3ITd0fXqwhWKnTgni20%3D&reserved=0 > > root@DESKTOP-OOHD5UG [ ~ ]# uname -a > Linux DESKTOP-OOHD5UG 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri > Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux > I wonder if you have an option to test with LTS kernel >= 5.15.154 because that contains many fanotify backports from a much more recent kernel. > On collecting the strace of the operation(git clone <repo link>), it is found that renaming file name from .git/config.lock to .git/config and subsequent read of that latter is failing. > Failing with which error? Can you provide the strace output? > Any known issues in this regard ? > > Let us know if you require further information. Which mount options for 9p? is fscache enabled? Are you reporting a kernel regression? IOW, did this test case ever work with 9p as far as you know? Unless you are reporting a kernel regression this might be an issue of MDE over 9p, so will need debugging information about the decisions that MDE makes. Thanks, Amir.
Attachment:
nw_clone.strace
Description: nw_clone.strace
