summaryrefslogtreecommitdiffstats
path: root/fs/nfsd
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
parentb7299f44394336f51b526247a870d47d28f4f97c (diff)
downloadlinux-47cee541a46a73b20dc279bf4c4690f776f6c81b.tar.gz
linux-47cee541a46a73b20dc279bf4c4690f776f6c81b.tar.bz2
linux-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')
-rw-r--r--fs/nfsd/nfs4state.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 84b0fe9a262a..296eded356b6 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1757,12 +1757,12 @@ alloc_init_file(struct inode *ino)
INIT_LIST_HEAD(&fp->fi_hash);
INIT_LIST_HEAD(&fp->fi_stateids);
INIT_LIST_HEAD(&fp->fi_delegations);
- spin_lock(&recall_lock);
- list_add(&fp->fi_hash, &file_hashtbl[hashval]);
- spin_unlock(&recall_lock);
fp->fi_inode = igrab(ino);
fp->fi_id = current_fileid++;
fp->fi_had_conflict = false;
+ spin_lock(&recall_lock);
+ list_add(&fp->fi_hash, &file_hashtbl[hashval]);
+ spin_unlock(&recall_lock);
return fp;
}
return NULL;