diff options
author | Pavel Emelyanov <xemul@openvz.org> | 2010-05-17 20:00:37 +0400 |
---|---|---|
committer | J. Bruce Fields <bfields@citi.umich.edu> | 2010-05-18 12:05:20 -0400 |
commit | 47cee541a46a73b20dc279bf4c4690f776f6c81b (patch) | |
tree | d54461a8fd6a4c70d5b092334ccf38359bcd4994 /fs/nfsd/nfscache.c | |
parent | b7299f44394336f51b526247a870d47d28f4f97c (diff) | |
download | linux-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