Searched hist:"3 d02fa29" (Results 1 – 1 of 1) sorted by relevance
/openbmc/linux/fs/nfsd/ |
H A D | nfs4state.c | 3d02fa29 Mon Sep 19 14:07:41 CDT 2011 J. Bruce Fields <bfields@redhat.com> nfsd4: fix open downgrade, again
Yet another open-management regression:
- nfs4_file_downgrade() doesn't remove the BOTH access bit on downgrade, so the server's idea of the stateid's access gets out of sync with the client's. If we want to keep an O_RDWR open in this case, we should do that in the file_put_access logic rather than here. - We forgot to convert v4 access to an open mode here.
This logic has proven too hard to get right. In the future we may consider: - reexamining the lock/openowner relationship (locks probably don't really need to take their own references here). - adding open upgrade/downgrade support to the vfs. - removing the atomic operations. They're redundant as long as this is all under some other lock.
Also, maybe some kind of additional static checking would help catch O_/NFS4_SHARE_ACCESS confusion.
Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> 3d02fa29 Mon Sep 19 14:07:41 CDT 2011 J. Bruce Fields <bfields@redhat.com> nfsd4: fix open downgrade, again Yet another open-management regression: - nfs4_file_downgrade() doesn't remove the BOTH access bit on downgrade, so the server's idea of the stateid's access gets out of sync with the client's. If we want to keep an O_RDWR open in this case, we should do that in the file_put_access logic rather than here. - We forgot to convert v4 access to an open mode here. This logic has proven too hard to get right. In the future we may consider: - reexamining the lock/openowner relationship (locks probably don't really need to take their own references here). - adding open upgrade/downgrade support to the vfs. - removing the atomic operations. They're redundant as long as this is all under some other lock. Also, maybe some kind of additional static checking would help catch O_/NFS4_SHARE_ACCESS confusion. Cc: stable@kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
|