forked from luck/tmp_suning_uos_patched
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>
This commit is contained in:
parent
b7299f4439
commit
47cee541a4
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user