Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database

From: J. Bruce Fields
Date: Fri Jul 02 2004 - 12:01:12 EST


On Fri, Jul 02, 2004 at 09:39:40AM -0700, Yichen Xie wrote:
> indeed, the code looks different in 2.6.7. definitely not a double unlock
> any more, but it seems the new version exit w/ client_sema unheld at line
> 1616, and w/ the lock held at line 1625. is there a correlation between
> the return value with the lock state? -yichen

Yes. The unlock happens at either nfs4xdr.c:1280 (ENCODE_SEQID_OP_TAIL)
or nfs4xdr.c:2534 (nfsd4_encode_replay()), and in the former case the
unlock is conditional on the value of the oc_stateowner field that's set
before the nfs4_lock_state() in nfsd4_open_confirm().

So while I believe the code as it stands is correct, it's not just your
checker that's going to find this confusing! I'll work on a fix....--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/