• Jeff Layton's avatar
    locks: protect most of the file_lock handling with i_lock · 1c8c601a
    Jeff Layton authored
    Having a global lock that protects all of this code is a clear
    scalability problem. Instead of doing that, move most of the code to be
    protected by the i_lock instead. The exceptions are the global lists
    that the ->fl_link sits on, and the ->fl_block list.
    ->fl_link is what connects these structures to the
    global lists, so we must ensure that we hold those locks when iterating
    over or updating these lists.
    Furthermore, sound deadlock detection requires that we hold the
    blocked_list state steady while checking for loops. We also must ensure
    that the search and update to the list are atomic.
    For the checking and insertion side of the blocked_list, push the
    acquisition of the global lock into __posix_lock_file and ensure that
    checking and update of the  blocked_list is done without dropping the
    lock in between.
    On the removal side, when waking up blocked lock waiters, take the
    global lock before walking the blocked list and dequeue the waiters from
    the global list prior to removal from the fl_block list.
    With this, deadlock detection should be race free while we minimize
    excessive file_lock_lock thrashing.
    Finally, in order to avoid a lock inversion problem when handling
    /proc/locks output we must ensure that manipulations of the fl_block
    list are also protected by the file_lock_lock.
    Signed-off-by: 's avatarJeff Layton <jlayton@redhat.com>
    Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
svcsubs.c 10.1 KB