summaryrefslogtreecommitdiff
path: root/tools/build
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@redhat.com>2015-11-25 01:43:03 +0300
committerJ. Bruce Fields <bfields@redhat.com>2015-12-23 18:08:14 +0300
commitd4f72cb7fa4a3705f6675f2740f9713dc3400dd3 (patch)
tree1356010950af31d934e82adfd8e490b23c765763 /tools/build
parent414ca017a54d26c3a58ed1504884e51448d22ae1 (diff)
downloadlinux-d4f72cb7fa4a3705f6675f2740f9713dc3400dd3.tar.xz
nfsd: don't base cl_cb_status on stale information
The rpc client we use to send callbacks may change occasionally. (In the 4.0 case, the client can use setclientid/setclientid_confirm to update the callback parameters. In the 4.1+ case, sessions and connections can come and go.) The update is done from the callback thread by nfsd4_process_cb_update, which shuts down the old rpc client and then creates a new one. The client shutdown kills any ongoing rpc calls. There won't be any new ones till the new one's created and the callback thread moves on. When an rpc encounters a problem that may suggest callback rpc's aren't working any longer, it normally sets NFSD4_CB_DOWN, so the server can tell the client something's wrong. But if the rpc notices CB_UPDATE is set, then the failure may just be a normal result of shutting down the callback client. Or it could just be a coincidence, but in any case, it means we're runing with the old about-to-be-discarded client, so the failure's not interesting. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'tools/build')
0 files changed, 0 insertions, 0 deletions