Bug #15679
openopen race in NFS4 server
0%
Description
When one client does an open on a non-existent file while another client issues a remove on that name we can end up with an unlinked file that can live forever (and occupy space):
Thread a: open. Thread b: remove
a: enters rfs4_do_opennull
a: creates the file in rfs4_createfile
a: saves the vnode to cs->vp
a: block in VOP_FSYNC
b: remove the newly created file (nlink == 0, still referenced)
a: leave rfs4_createfile, enter rfs4_do_open
a: create a new nfs state for that file based on the saved vnode
a: return the filehandle to the caller
All subsequent nfs-calls from client a for that file now fail with STALE, so the client has no way to release the reference on that file. Only when the client goes away completely the file gets released. This is fairly easy to reproduce due to the block in FSYNC, which open the window for the race condition.
No data to display