[OpenAFS-devel] SOLARIS/osi_vnops.c

[aeneous@speakeasy.org]

Ok, I haven't looked at the rw_tryupgrade code so this is a guess...

The background is that some piece of code is holding a shared lock and 
wants an exclusive lock instead.  You can't just drop the shared lock
and grab the exclusive lock, because you may race with other code between the 
two events.  So you need a way to get the new lock and release the old lock 
atomically.  You can't hold them both simultaneously because they conflict 
with each other.

I think rw_tryupgrade is supposed to obtain the exclusive lock IFF it can do 
so without blocking -- in other words, if no race is possible.  Otherwise, it 
should return failure.  So this AFS_TRYUP routine is saying "yeah, ok, so we 
couldn't get the upgraded lock without racing.  So what, then, race away."

This is just nuts.  If that's the desired behavior, then why even bother with 
tryupgrade in the first place?  And I would be very suspicious that permitting 
this race is acceptable.