[LinuxFailSafe] cdbd and fs2d_lock_node

[Kashif Shaikh]

I've been looking at the cdbd's transaction system, and some bits of
code are counter-intuitive to me.  I hope one of you or both of you can
answer some questions I have.

In the case of fs2_write_lock, this is the lock graph (assume blocking
locks):

NOLOCK := no lock
READ = read lock
WRITE := write lock
CP := Calling/Current FS2 Process (i.e. lock is held by current
transaction)
DP := Different FS2 Process(i.e. lock is held by different transaction)
NP1 := Arbitrary Node Pointer 1
NP2 := Arbitrary Node Pointer 2

Node Lock State   | Request Lock by CP | Lock Result
---------------------------------------------
NOLOCK(NP1)	  | WRITE(NP1)         | OK
WRITE (NP1) by CP | WRITE(NP2)         | OK, Lock upgrade.
READ  (NP1) by CP | WRITE(NP1)	       | FAILED.
WRITE (NP1) by DP | WRITE(NP1)         | WAIT_FOR_LOCK(sleep)
READ  (NP1) by DP | WRITE(NP1)	       | OK!!!???

When looking at the code, the last case should block as deemed by
fs2d_find_lock_conflict, but it doesn't in reality.  From my inspection,
when acquiring a read lock, the transaction is not binded to the NP.
This is a bug(I think it is)? Or has some sly unattended effect?

Now when we look at fs2_read_lock, I see some 'does not look right'
cases:

Node Lock State   | Request Lock by CP | Lock Result
---------------------------------------------
NOLOCK(NP1)	  | READ(NP1)          | OK
READ  (NP1) by CP | READ(NP2)          | OK, Lock upgrade.
WRITE (NP1) by CP | READ(NP1)	       | OK, NO-OP, Keep lock as RW
READ  (NP1) by DP | READ(NP1)	       | OK
WRITE (NP1) by DP | READ(NP1)          | OK!!!???

The last case is critical, though according to the code, I don't see any
lock conflict performed by current process's attempt to acquire a read
lock on a node that has been write locked by another process.

Why is this the case? Intuitively, I would expect the process to block,
but it doesn't! At the very least, it should fail.  Are there some
assumptions being made, for which I'm not aware of? Or are cdbd locking
semantics completely different from the norm?

Sorry for asking you two so many questions :)

Regards,

Kashif Shaikh