lkml.org 
[lkml]   [2002]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectfs/locks.c BKL removal
Matthew,
Al Viro pointed me your way.

I'm looking into the fs/locks.c mess. It appears that there was an
attempt to convert this over to a semaphore, but it was removed just
before the 2.4 release because of some deadlocks.

Whenever the i_flock list is traversed, the BKL is held. It is also
held while running through the file_lock_list which I think is used
only for /proc/locks.

We definitely need a semaphore because of all the blocking that goes
on. We can either have a global lock for all of them, which I think
was tried last time. Or, we can split it up a bit more. With the
current design, there will need to be a lock for the global list, each
individual list, and one for each individual lock to protect against
access from the reference in the file_lock_list and the inode->i_flock
list.

However, I think that the file_lock_list complexity may be able to be
reduced. If we make the file_lock_list a list of inodes (or just the
i_flocks) with active locks, we can avoid the complexity of having an
individual file_lock lock. That way, we at least reduce the number of
_types_ of locks. It increases the number of dereferences, but this
is /proc we're talking about. Any comments?

Talking about locks for locks is confusing :)

--
Dave Hansen
haveblue@us.ibm.com

-
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 13:26    [W:0.088 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site