Re: lock issues
From: Herbert Poetzl
Date: Tue Oct 12 2004 - 09:28:33 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/