summaryrefslogtreecommitdiffstats
path: root/fs/nfsd/nfscache.c
diff options
context:
space:
mode:
authorPavel Emelyanov <xemul@openvz.org>2010-05-17 20:00:37 +0400
committerJ. Bruce Fields <bfields@citi.umich.edu>2010-05-18 12:05:20 -0400
commit47cee541a46a73b20dc279bf4c4690f776f6c81b (patch)
treed54461a8fd6a4c70d5b092334ccf38359bcd4994 /fs/nfsd/nfscache.c
parentb7299f44394336f51b526247a870d47d28f4f97c (diff)
downloadlinux-stable-47cee541a46a73b20dc279bf4c4690f776f6c81b.tar.gz
linux-stable-47cee541a46a73b20dc279bf4c4690f776f6c81b.tar.bz2
linux-stable-47cee541a46a73b20dc279bf4c4690f776f6c81b.zip
nfsd: safer initialization order in find_file()
The alloc_init_file() first adds a file to the hash and then initializes its fi_inode, fi_id and fi_had_conflict. The uninitialized fi_inode could thus be erroneously checked by the find_file(), so move the hash insertion lower. The client_mutex should prevent this race in practice; however, we eventually hope to make less use of the client_mutex, so the ordering here is an accident waiting to happen. I didn't find whether the same can be true for two other fields, but the common sense tells me it's better to initialize an object before putting it into a global hash table :) Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Diffstat (limited to 'fs/nfsd/nfscache.c')
0 files changed, 0 insertions, 0 deletions