Messages in this thread | | | Date | Thu, 21 Mar 2013 22:33:27 -0700 | Subject | Re: [CFT] Re: VFS deadlock ? | From | Linus Torvalds <> |
| |
On Thu, Mar 21, 2013 at 10:18 PM, Al Viro <viro@zeniv.linux.org.uk> wrote: >> >> This seems too simple, but I don't see why iget_locked() would be any >> better. It just wastes time hashing the inode that we aren't really >> interested in hashing. The inode is always filled by the caller >> anyway, so we migth as well just get a fresh pseudo-filesystem inode >> without any crazy hashing.. > > Umm... > static int proc_delete_dentry(const struct dentry * dentry) > { > return 1; > } > > static const struct dentry_operations proc_dentry_operations = > { > .d_delete = proc_delete_dentry, > }; > > IOW, dcache retention in procfs is inexistent and the damn thing tries > to cut down on the amount of inode allocation/freeing/filling.
Ok, that's kind of ugly, but shouldn't be a correctness issue. It should still work - just cycle through inodes quite aggressivelydue to no longer re-using them - so I suspect Dave could test it (with the extra line removed I pointed out just a moment ago).
And I wonder how big of a deal the aggressive dentry deletion is. Maybe it's even ok to allocate/free the inodes all the time. The whole "get the inode hash lock and look it up there" can't be all that wonderful either. It takes the inode->i_lock for each entry it finds on the hash list, which looks horrible. I suspect our slab allocator isn't much worse than that, although the RCU freeing of the inodes could end up being problematic.
Linus
| |