Messages in this thread | | | Date | Fri, 22 Mar 2013 05:18:17 +0000 | From | Al Viro <> | Subject | Re: [CFT] Re: VFS deadlock ? |
| |
On Thu, Mar 21, 2013 at 09:55:10PM -0700, Linus Torvalds wrote: > However, I do wonder if we could take another approach... There's > really no reason why we should look up an old inode with iget_locked() > in proc_get_inode() and only fill it in if it is new. We might as well > just always create a new inode. The "iget_locked()" logic really comes > from the bad old days when the inode was the primary data structure, > but it's really the dentry that is the important data structure, and > the inode might as well follow the dentry, instead of the other way > around. > > So why not just use "new_inode_pseudo()" instead? IOW, something like > this (totally untested, natch) patch? This way, if you have a new > dentry, you are guaranteed to always have a new inode. None of the > silly inode alias issues.. > > 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.
I agree that we could get rid of icache retention there and everything ought to keep working. Hell knows... It applies only to the stuff that isn't per-process, so it's probably not particulary hot anyway, but it does need profiling... OTOH, we probably could mark "stable" dentries in some way and let proc_delete_dentry() check that flag in proc_dir_entry - I seriously suspect that really hot non-per-process ones are of the "never become invalid" variety.
| |