Tejun Heo <[EMAIL PROTECTED]> writes: > Hello, Eric. > > Eric W. Biederman wrote: >> I will look a little more and see. But right now it looks like the >> real problem with locking is that we use sysfs_mutex to lock the >> sysfs_dirent s_children list. >> >> Instead it really looks like we should use i_mutex from the appropriate >> inode. Or is there a real performance problem with forcing the directory >> inodes in core when we modify the directories? > > I don't think there is any performance problem. Problems with using > i_mutex were... > > * It was messy. I don't remember all the details now but IIRC symlink > walk code was pretty complex. > > * And more importantly, inodes are reclaimable and might or might not be > there.
Yes. But we can always force inodes into the cache when we need them. When I complete it I will have to show you a patch using the inode lock for locking directory modifications. From what I can tell so far it allows me to fix the weird lock order problems and generally simplify the locking. Eric _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
