Kernel lockmgr races LK_UPGRADE against LK_SHARED...

This is on 4.x, but I'm posting to current, it's likely also
an issue on current. Posting here hoping someone can shed 
more info on this lockmgr race.

I've into a bug where process 1 successfully LK_UPGRADEs a
vnode lock (from shared to excl) and process 2 successfully 
acquires the shared lock on that same vnode. I am not sure
what order the locks were acquired, it's not possible to 
infer that from the core.

Does this bug ring a bell with anyone ? If it does, can they 
shed any light/info they might have on this ?

thanks

mohan