[OpenAFS-devel] trying to make sense of afs_vnop_flock.c

[Nathan Neulinger]

I'm trying to figure out this code to where I can look at having a try
at clientside byte-range locking. Would appreciate any comments from
others more in tune with kernel internals... Some of this is very stream
of thought, so please excuse the babbling.


So far, since everything is based in terms of flock, and flock doesn't
do byte ranges at all, looks like I'll need to basically scrap the whole
lot and rework from scratch - basically in reverse, doing more like
fcntl, but generalized. In some respects, that seems a bit easier.

A place I'm not really clear on - in afs_xflock, it looks like a mix of
afs doing it's own lock tracking, as well as updating fields in the
kernel file descriptor recording lock states, and calling flock() if
!flockDone. Why would the lock not have been done?

It looks like getf() is returning a kernel file handle of some sort, and
f_flag in that is being used to keep track of whether any exclusive or
shared lock exists on the file. (Not sure what purpose that serves.)

With brlocks, the potential exists for ranges of the file to be locked
for read, and independent ranges to be locked for write at the same
time, seems to me that the only way this will be managed is for the lock
on the server to be the most upgraded version - i.e. if there are only
read locks in place, would be sufficient to have a single read lock on
server, but the moment a write lock is needed, the server lock would
have to be upgraded to a write lock. In an of itself, this doesn't seem
like a big problem - the code already has examples of lock upgrades.


There are a number of references to avc->flockCount, these obviously
would no longer be meaningful, as the semantics will have changed.
(Could possibly have both readers and writers at same time.) I'd presume
on perhaps changing it's meaning to just a count of locks on the file,
both R+RW. 


Is the number in ObtainWriteLock for src purely an arbitrary one - i.e.
just try to keep unique throughout code for debugging purposes?

Are there are special restrictions on use of osi_AllocSmallSpace? Looks
like it's already used in this case to build the SimpleLocks linked
list. Should that avoid allocating very much memory? or is it just meant
for allocating a small piece of memory (as opposed to a large piece at a
time).

Looks like I should actually be able to use the SimpleLocks structure
with only minor changes. 

It seems like there is a race condition in the locking protocol with the
server - to do a lock upgrade, it releases the lock, and then requests a
new one. Don't know if that has much impact, seems like it could be
dangerous if you attempt to upgrade a R to an RW while there are other
processes/clients waiting on an RW at the same time. 



Any comments, especially "You're heading off in the completely wrong
direction" ones, would be appreciated.

Other than some of the kernel issues I'm not sure about, I think I've
got a pretty clear picture in my head of how I'll work this, and it
should actually simplify things a bit. 


-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216