Red Hat Bugzilla – Bug 833746
Wrong byte order in comparison causes a wrong return value from function nlmclnt_cancel
Last modified: 2012-11-27 10:16:16 EST
When NLM client sends a lock command, it will wait a certain amount of time after which it will give up and send a cancel command.
In some situations, the lock may actually be granted although the reply was delayed so the cancel command will fail, which will cause the kernel to send an unlock.
This situation is tested in nlmclnt_cancel by the line:
(status == 0 && req->a_res.status == nlm_lck_denied)
The problem here is that req->a_res.status is returned in host byte order while nlm_lck_denied is defined in network byte order, so the comparison fails.
(In reply to comment #0)
> The problem here is that req->a_res.status is returned in host byte order
Are you sure about that? Looking at the code, I see a_res.status is defined in include/linux/lockd/xdr.h as __be32 (hence network order), and fs/lockd/xdr.c:nlmsvc_decode_res() does indeed read it without any byte-swapping.
What kernel exactly are you testing? It looks like some fixes in this area went in to 2.6.18-247.el5.
I saw the fix put in between RHEL5.6 kernel and RHEL5.7.
I think it's a case of misinformation on our side regarding the kernel on which this problem was witnessed. I usually detect these issues while going through the set of patches, but RHEL5.7 no longer has the specific patch organization that exists in RHEL5.6.
Sorry for the hassle.
OK, thanks. Then it looks like the correct thing is to close this as a dup of the (already closed) 526829.
*** This bug has been marked as a duplicate of bug 526829 ***