summaryrefslogtreecommitdiffstats
path: root/arch/x86/xen
diff options
context:
space:
mode:
authorXiubo Li <xiubli@redhat.com>2024-07-12 12:40:19 +0800
committerIlya Dryomov <idryomov@gmail.com>2024-08-01 13:14:28 +0200
commit31634d7597d8c57894b6c98eeefc9e58cf842993 (patch)
treec67c855918e239e61e4e5bcc45bd2bb8951e240a /arch/x86/xen
parent8400291e289ee6b2bf9779ff1c83a291501f017b (diff)
downloadlinux-31634d7597d8c57894b6c98eeefc9e58cf842993.tar.gz
linux-31634d7597d8c57894b6c98eeefc9e58cf842993.tar.bz2
linux-31634d7597d8c57894b6c98eeefc9e58cf842993.zip
ceph: force sending a cap update msg back to MDS for revoke op
If a client sends out a cap update dropping caps with the prior 'seq' just before an incoming cap revoke request, then the client may drop the revoke because it believes it's already released the requested capabilities. This causes the MDS to wait indefinitely for the client to respond to the revoke. It's therefore always a good idea to ack the cap revoke request with the bumped up 'seq'. Currently if the cap->issued equals to the newcaps the check_caps() will do nothing, we should force flush the caps. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/61782 Signed-off-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Venky Shankar <vshankar@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Diffstat (limited to 'arch/x86/xen')
0 files changed, 0 insertions, 0 deletions