On Wed, Jan 25, 2017 at 4:06 PM, Marko Rauhamaa <marko.rauhamaa@xxxxxxxxxxxx> wrote: > Amir Goldstein <amir73il@xxxxxxxxx>: > >> On Wed, Jan 25, 2017 at 1:48 PM, Marko Rauhamaa >> <marko.rauhamaa@xxxxxxxxxxxx> wrote: >>> We have run into an easily reproducible fanotify hang that affects >>> several distros as well as the latest development kernel. (It isn't >>> fixed by Amir Goldstein's recent fanotify patch, BTW.) >> >> Not sure what is the role that autofs is playing in this hang, but it >> is worth checking if Jan's latest work fixes the problem. I estimate >> that it should, because it isolated the user space handling of >> permission events from affecting processes generating fsnotify events >> on other fs objects. >> >> git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git #for_testing > > I could try. > >>> 4. Observe the last command hang. While it is hung, other file system >>> operations from other processes are blocked. >> >> You mean other processes not trying to access objects under the >> watched mounts. right? > > No, accessing the watched mounts. Don't know if the hang is limited to > them. So I am confused. Your test program sets a watch on permission events on the mount and does not respond to permission events on the mount, so all file system operations on the mount SHOULD be blocked. What am I missing? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
