lkml.org 
[lkml]   [2004]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: lock issues
From
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.401 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site