lkml.org 
[lkml]   [2012]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: processes hung after sys_renameat, and 'missing' processes
    On Thu, Jun 07, 2012 at 08:36:07PM +0100, Al Viro wrote:

    > Other callers of d_move():
    > * debugfs_rename() - imitates what vfs_rename() is doing. Same
    > locking environment. BTW,
    > trap = lock_rename(new_dir, old_dir);
    > /* Source or destination directories don't exist? */
    > if (!old_dir->d_inode || !new_dir->d_inode)
    > goto exit;
    > is bogus - lock_rename() is taking ->i_mutex on these inodes, for fsck sake!
    > If this can be called with old_dir or new_dir negative, it's buggered.

    It's worse, actually. If we _ever_ do cross-directory debugfs_rename()
    without external serialization, we are in trouble. It does imitate
    vfs_rename() (actually - its callers), but there's an unpleasant difference:
    instead of "lock parents with lock_rename(), then do lookups and we are
    guaranteed nobody will change ->d_parent of children we are working with"
    it's "lock the new parent and whatever happens to be the current parent
    of the object given to us; do lookup for target, pray that the old parent
    still was the parent of our object by the time we got the locks".

    AFAICS, there's only one caller doing cross-directory moves (__clk_reparent())
    and currently all callers are serialized by a mutex in there, but that's
    not documented anywhere - not for __clk_reparent(), not for debugfs_rename().


    \
     
     \ /
      Last update: 2012-06-08 05:01    [W:4.887 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site