aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/netdev-times.py
diff options
context:
space:
mode:
authorJeff Layton <[email protected]>2011-11-04 13:31:21 -0400
committerTrond Myklebust <[email protected]>2011-11-04 16:39:04 -0400
commit1788ea6e3b2a58cf4fb00206e362d9caff8d86a7 (patch)
tree24846fddf8b55f516f365a735defd79b6ea6d28a /tools/perf/scripts/python/netdev-times.py
parent1583171492eb514e267c7b51e96846b38de0f544 (diff)
nfs: when attempting to open a directory, fall back on normal lookup (try #5)
commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return from an OPEN call. Prior to that patch, that caused the client to fall back to doing a normal lookup. When that patch went in, the code began returning that error to userspace. The d_revalidate codepath however never had the corresponding change, so it was still possible to end up with a NULL ctx->state pointer after that. That patch caused a regression. When we attempt to open a directory that does not have a cached dentry, that open now errors out with EISDIR. If you attempt the same open with a cached dentry, it will succeed. Fix this by reverting the change in nfs_atomic_lookup and allowing attempts to open directories to fall back to a normal lookup Also, add a NFSv4-specific f_ops->open routine that just returns -ENOTDIR. This should never be called if things are working properly, but if it ever is, then the dprintk may help in debugging. To facilitate this, a new file_operations field is also added to the nfs_rpc_ops struct. Cc: [email protected] Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/netdev-times.py')
0 files changed, 0 insertions, 0 deletions