mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
nfsd: stop pretending that we cache the SEQUENCE reply.
nfsd does not cache the reply to a SEQUENCE. As the comment above nfsd4_replay_cache_entry() says: * The sequence operation is not cached because we can use the slot and * session values. The comment above nfsd4_cache_this() suggests otherwise. * The session reply cache only needs to cache replies that the client * actually asked us to. But it's almost free for us to cache compounds * consisting of only a SEQUENCE op, so we may as well cache those too. * Also, the protocol doesn't give us a convenient response in the case * of a replay of a solo SEQUENCE op that wasn't cached The code in nfsd4_store_cache_entry() makes it clear that only responses beyond 'cstate.data_offset' are actually cached, and data_offset is set at the end of nfsd4_encode_sequence() *after* the sequence response has been encoded. This patch simplifies code and removes the confusing comments. - nfsd4_is_solo_sequence() is discarded as not-useful. - nfsd4_cache_this() is now trivial so it too is discarded with the code placed in-line at the one call-site in nfsd4_store_cache_entry(). - nfsd4_enc_sequence_replay() is open-coded in to nfsd4_replay_cache_entry(), and then simplified to (hopefully) make the process of replaying a reply clearer. Signed-off-by: NeilBrown <neil@brown.name> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
This commit is contained in:
parent
8320b75b2b
commit
fceb8734e7
2 changed files with 18 additions and 61 deletions
Loading…
Add table
Add a link
Reference in a new issue