[LU-16004] Blocking callback for already cancelling lock that would have no IO

Related — Mon, 22 Jan 2024 16:29:35 +0000

It looks like when we have blocking callback come for a lock that is already undergoing canceling (canceling bit is set), we just tell the server "hey, we got your request, we'll get back to you" and then wait for the cancel procedure to finish.

But while this makes sense for a lock that is stuck doing e.g. writeout of pages, sometimes locks are stuck as canceling because they are caught in lru cleanup or whatever other reasons (which seems particularly common when the server latency is high).

It looks like returning EINVAL for such locks (as if it was already fully canceled and the AST just lost the race) for PR/CR and also potentially PW locks with discard dirty data flag set (though this one is tricky since the writeout might have been originated already before this flag was delivered? perhaps once we have server side enforcement of valid lock coverage and rejecting all writes without a lock that'd be safe?) would speed up other clients that wanted to get this lock to do whatever it is they need doing.

Extra wrinkle here is that the ldlm_handle_bl_callback() is called after we ship the reply so some additional potentially not very trivial code rearrangement might need to happen to make such a reply feasible unless we just do it simplistically upfront once the lock handle to lock was matched.

Whamcloud Community JIRA

[LU-16004] Blocking callback for already cancelling lock that would have no IO