lock issues

lock issues

[Herbert Poetzl]

Hi Trond!

experiencing the following panic on a linux-vserver
kernel (2.6.9-rc4, no modifications to locking)

Kernel panic - not syncing: Attempting to free lock with active block list

it's not easy to trigger but it happens now and then.
after adding a dump_stack() in panic() this is the trace

[<8011b945>] panic+0x55/0xe0		       
[<80174897>] fcntl_setlk64+0x137/0x2d0         
[<80119540>] autoremove_wake_function+0x0/0x60 
[<80179aba>] dnotify_parent+0x3a/0xb0	       
[<8015dc49>] fget+0x49/0x60		       
[<8016fa5b>] sys_fcntl64+0x4b/0xa0	       
[<8010426f>] syscall_call+0x7/0xb

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?

TIA,
Herbert

Re: lock issues

[Trond Myklebust]

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)?

> 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?

Anyhow, that would indeed be papering over an issue in the posix lock
case. 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.

Cheers,
  Trond

Re: lock issues

[Herbert Poetzl]

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

Re: lock issues

[Olivier Poitrey]

Herbert Poetzl <herbert@13thfloor.at> writes:

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

Yeah, that's correct.

Here is the panic + trace with a vanilla kernel (no vserver patch):

Kernel panic - not syncing: Attempting to free lock with active block list
 [<c011aa15>] panic+0x55/0xe0
 [<c0168277>] fcntl_setlk64+0x137/0x2d0
 [<c010c5ac>] restore_i387_fxsave+0xac/0xb0
 [<c010c64d>] restore_i387+0x9d/0xa0
 [<c0151cd9>] fget+0x49/0x60
 [<c01635eb>] sys_fcntl64+0x4b/0xa0
 [<c010427f>] syscall_call+0x7/0xb

The panic seems to be caused by a proftpd version 1.2.9 on a Debian
Sarge. The whole distribution is mounted over NFS and both client and
server are using the 2.6.9-rc4 kernel version.

The proftpd configuration isn't that unusual except that a directory
is mounted rbinded but it doesn't seem to be the problem because I get
the same panic without it. I can provide the proftpd configuration if
needed it.

Let me know if you need some more information.

-- 
Olivier Poitrey