user/sven/linux.git/include/linux/dcache.h, branch v3.10.44

cope with potentially long ->d_dname() output for shmem/hugetlb

2013-10-18T14:45:45Z

commit 118b23022512eb2f41ce42db70dc0568d00be4ba upstream. dynamic_dname() is both too much and too little for those - the output may be well in excess of 64 bytes dynamic_dname() assumes to be enough (thanks to ashmem feeding really long names to shmem_file_setup()) and vsnprintf() is an overkill for those guys. Signed-off-by: Al Viro Cc: Colin Cross Signed-off-by: Greg Kroah-Hartman

vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op

2013-02-26T07:46:09Z

The following set of operations on a NFS client and server will cause server# mkdir a client# cd a server# mv a a.bak client# sleep 30 # (or whatever the dir attrcache timeout is) client# stat . stat: cannot stat `.': Stale NFS file handle Obviously, we should not be getting an ESTALE error back there since the inode still exists on the server. The problem is that the lookup code will call d_revalidate on the dentry that "." refers to, because NFS has FS_REVAL_DOT set. nfs_lookup_revalidate will see that the parent directory has changed and will try to reverify the dentry by redoing a LOOKUP. That of course fails, so the lookup code returns ESTALE. The problem here is that d_revalidate is really a bad fit for this case. What we really want to know at this point is whether the inode is still good or not, but we don't really care what name it goes by or whether the dcache is still valid. Add a new d_op->d_weak_revalidate operation and have complete_walk call that instead of d_revalidate. The intent there is to allow for a "weaker" d_revalidate that just checks to see whether the inode is still good. This is also gives us an opportunity to kill off the FS_REVAL_DOT special casing. [AV: changed method name, added note in porting, fixed confusion re having it possibly called from RCU mode (it won't be)] Cc: NeilBrown Signed-off-by: Jeff Layton Signed-off-by: Al Viro

constify d_lookup() arguments

2013-02-23T04:31:35Z

Signed-off-by: Al Viro

constify __d_lookup() arguments

2013-02-23T04:31:35Z

Signed-off-by: Al Viro

vfs: remove d_path_with_unreachable

2013-02-23T04:31:33Z

The last caller was removed >2 years ago in commit 7b2a69ba7. Signed-off-by: Jeff Layton Signed-off-by: Al Viro

vfs: remove DCACHE_NEED_LOOKUP

2012-12-20T18:57:36Z

The code that relied on that flag was ripped out of btrfs quite some time ago, and never added back. Josef indicated that he was going to take a different approach to the problem in btrfs, and that we could just eliminate this flag. Cc: Josef Bacik Signed-off-by: Jeff Layton Signed-off-by: Al Viro

vfs: dcache: use DCACHE_DENTRY_KILLED instead of DCACHE_DISCONNECTED in d_kill()

2012-09-18T18:23:51Z

IBM reported a soft lockup after applying the fix for the rename_lock deadlock. Commit c83ce989cb5f ("VFS: Fix the nfs sillyrename regression in kernel 2.6.38") was found to be the culprit. The nfs sillyrename fix used DCACHE_DISCONNECTED to indicate that the dentry was killed. This flag can be set on non-killed dentries too, which results in infinite retries when trying to traverse the dentry tree. This patch introduces a separate flag: DCACHE_DENTRY_KILLED, which is only set in d_kill() and makes try_to_ascend() test only this flag. IBM reported successful test results with this patch. Signed-off-by: Miklos Szeredi Cc: Trond Myklebust Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds

stop passing nameidata * to ->d_revalidate()

2012-07-14T12:34:14Z

Just the lookup flags. Die, bastard, die... Signed-off-by: Al Viro

vfs: switch i_dentry/d_alias to hlist

2012-07-14T12:32:55Z

Signed-off-by: Al Viro

vfs: make it possible to access the dentry hash/len as one 64-bit entry

2012-05-11T02:54:35Z

This allows comparing hash and len in one operation on 64-bit architectures. Right now only __d_lookup_rcu() takes advantage of this, since that is the case we care most about. The use of anonymous struct/unions hides the alternate 64-bit approach from most users, the exception being a few cases where we initialize a 'struct qstr' with a static initializer. This makes the problematic cases use a new QSTR_INIT() helper function for that (but initializing just the name pointer with a "{ .name = xyzzy }" initializer remains valid, as does just copying another qstr structure). Signed-off-by: Linus Torvalds