On Thu, Dec 8, 2022 at 7:29 AM Alexander Kozhevnikov <alexander.kozhevnikov@xxxxxxxxxxxxxxxxxxx> wrote: > Hi, Paul, > > Finally, I hope that I've got answers on all questions which were found > open on previous attempt: > 1) RCU accesses. There was a bug in printout code (isec pointers were > messed up with inode pointers), unfortunately. Now the picture is clear. > All inodes which were accessed on RCU-walk mode got another access in > Ref-walk mode right after and got successfully initialized. This is > exactly as VFS manual suggested. > 2) Inodes which are left without initialization are coupled with > directories which are mount points for some other filesystems and > according to VFS path lookup logic this dentries are substituted by > root dentries from underlying filesystems by handling mount points > during link_path_walk(). So this inodes do not have a chance to be > accessed until this mount points exist. As those generally are special > filesystems like /sys/fs/cgroup (very good example) there is almost no > chance for unmount of them. > The chain of events is quite simple: upper directory created, inode > added to deferred list, another filesystem mounted to this directory, > inode is not accessible anymore. > So, hope that this time I have quite good explanation of the story. Thanks for the update Alexander. It sounds like the VFS RCU fallback is working properly, which should address my worry about revalidating inodes while in a critical section. I would suggest updating your patchset based on the previous feedback and reposting. -- paul-moore.com
