On Wed, Feb 2, 2022 at 5:04 PM Bob Peterson wrote:
> Looks good. If you push it to a temp branch I'll test it.
The for-next branch fell a bit behind lately, but I've updated it now.
Thanks,
Andreas
The gh_error field if a glock holder is initialized to zero in
gfs2_holder_init(). When a locking operation fails, gh_error is set to
an error code; when it succeeds, the gh_error value is left unchanged.
The field isn't initialized in gfs2_holder_reinit(), which is a problem.
Instead of fixing th
Use list_is_first() instead of open-coding it.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 842884524ca7..f7f296e8e506 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -545,
On 2/2/22 10:55 AM, Andreas Gruenbacher wrote:
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In eithe
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the stat
Hi Bob,
On Mon, Jan 24, 2022 at 6:28 PM Bob Peterson wrote:
> Sometimes when gfs2 cancels a glock request, dlm needs time to take the
> request off its Conversion queue. During that time, we get -EBUSY from
> dlm, which confuses the glock state machine. Ideally we want dlm to
> not return -EBUSY
