| commit | 7ffdea7ea36cd1efebab65d1b221f05deaab00cd | |
| author | Al Viro <viro@ZenIV.linux.org.uk> | |
| Sat, 26 Jan 2013 00:11:36 +0000 (26 00:11 +0000) | ||
| committer | Eric Van Hensbergen <ericvh@gmail.com> | |
| Sun, 10 Feb 2013 22:29:33 +0000 (10 16:29 -0600) | ||
| tree | fb899d7da5e5774c102a70692fac779018b29df6 | treesnapshot (tar.gz zip) |
| parent | 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39 | commitdiff |
locking in fs/9p ->readdir()
... is really excessive. First of all, ->readdir() is serialized by
file->f_path.dentry->d_inode->i_mutex; playing with file->f_path.dentry->d_lock
is not buying you anything. Moreover, rdir->mutex is pointless for exactly
the same reason - you'll never see contention on it.
While we are at it, there's no point in having rdir->buf a pointer -
you have it point just past the end of rdir, so it might as well be a flex
array (and no, it's not a gccism).
Absolutely untested patch follows:
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
... is really excessive. First of all, ->readdir() is serialized by
file->f_path.dentry->d_inode->i_mutex; playing with file->f_path.dentry->d_lock
is not buying you anything. Moreover, rdir->mutex is pointless for exactly
the same reason - you'll never see contention on it.
While we are at it, there's no point in having rdir->buf a pointer -
you have it point just past the end of rdir, so it might as well be a flex
array (and no, it's not a gccism).
Absolutely untested patch follows:
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
| fs/9p/vfs_dir.c | diffblobblamehistory |