Re: lock issues

[Herbert Poetzl <herbert@13thfloor.at>]

On Tue, Oct 12, 2004 at 02:08:28AM +0200, Trond Myklebust wrote:
> På ty , 12/10/2004 klokka 00:57, skreiv Herbert Poetzl:
> > Hi Trond!
> > 
> > experiencing the following panic on a linux-vserver
> > kernel (2.6.9-rc4, no modifications to locking)
> 
> Which filesystem? Is this NFS or CIFS (which both have an f_op->lock()
> routine)?

NFS v3  options should be rw,intr,tcp,nfsvers=3
(not 100% sure)

> > it's the locks_free_lock(file_lock); at the end of 
> > fcntl_setlk64() and I'm asking myself if something
> > like in sys_flock()
> > 
> >         if (list_empty(&lock->fl_link)) {
> >                 locks_free_lock(lock);
> >         }
> > 
> > would help here or just paper over the real issue?
> 
> Actually, the sys_flock() thing looks a lot more iffy to me: why should
> list_empty(lock->fl_link) mean that you are responsible for freeing that
> lock? Couldn't a sibling or child thread have released it from
> underneath you?

btw, once the following messages where observed
right before the panic()

nlmclnt_lock: VFS is out of sync with lock manager!
nlmclnt_lock: VFS is out of sync with lock manager!
nlmclnt_lock: VFS is out of sync with lock manager!

but that was jsut in one case of many ...

> Anyhow, that would indeed be papering over an issue in the posix lock
> case. 

thought so .. but why the check for sys_flock() ?
(disclaimer: don't know the locking code)

> By the time we get to the end of fcntl_setlk64(), the file_lock
> should not be on any lists. If it got added to somebody else's block
> list, it should either have been unblocked when the region was freed, or
> in case of a signal, we remove it from the block list manually. Unlike
> the flock case, file_lock itself never gets added to the active list.

best,
Herbert

> Cheers,
>   Trond