DLM user API for blocking AST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Continuing with my experiments with the DLM user API, I am trying to use 
blocking AST callbacks, and find that the rules for the lifetime and 
ownership of the dlm_lksb struct are a bit surprising. This led me to some 
investigations, and the question at the end of this email.

It looks like the kernel remembers the pointer to the lksb struct used to 
issue the dlm_lock call, and libdlm happily overwrites this piece of 
memory whenever the kernel issues an event related to that lock, including 
just before firing a BAST callback. It is a bit frustrating because I got 
caught by surprise wondering why something was smashing my stack, ie. the 
place where I had once laid out my dlm_lksb, thinking that it was okay to 
release its memory after the completion AST callback has completed.

For now I have (apparently) working test code that deals with this in the 
following way: for a given lock (identified by its lockid), I keep two 
dlm_lksb structs and a bit indicating which of the two is free to use for 
conversions. I update the bit every time the CAST (not BAST) callback 
completes, thus doing some kind of double buffering.

So I assume that:

- each lock acquisition or conversion call gives ownership of the lksb to 
the kernel and libdlm (because a BAST callback can fire at any time and 
will overwrite the struct), causing the kernel/libdlm to forget about the 
previously owned lksb (meaning the caller can/should then dispose of it)

- AST and BAST callbacks run in order, such that after the CAST completes, 
and until a conversion occurs, a BAST firing will only overwrite the lksb 
given on the last lock or conversion

Are my assumptions correct?


Cheers,
Jean-Marc

-- 
saffroy@xxxxxxxxx

-- 
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster



[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux