[lkml]   [2013]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [REVIEW][PATCH 1/4] vfs: Don't allow overwriting mounts in the current mount namespace
    Al Viro <> writes:

    > On Fri, Nov 08, 2013 at 12:51:52PM -0800, Eric W. Biederman wrote:
    >> The return value of d_mountpoint can be obsolete as soon as it returns
    >> as well, so I don't see this as being significantly different.
    > Not if the ->i_mutex of that sucker is held. And it *is* held in
    > vfs_unlink/vfs_rmdir/vfs_rename. Note that we only care about a mountpoint
    > being falsely assumed to be a non-mountpoint - in the other direction we
    > can just shrug and say that we'd won the race and got EBUSY for that.

    I wasn't certain of your question. My point here was that covered() as
    a mechanism is as good as d_mountpoint. So the only potential issue
    with covered() as a mechanism is where covered() is called.

    Also please note old_dentry->d_inode->i_mutex is not held in rename.

    >> In 3.12 vfs_rmdir checks d_mountpoint with the
    >> dentry->d_inode->i_mutex and
    >> dentry->d_parent->d_inode->i_mutex held.
    >> In 3.12 vfs_unlink checks d_mountpoint with the
    >> dentry->d_inode->i_mutex and
    >> dentry->d_parent->d_inode->i_mutex hel.d
    >> In 3.12 vfs_rename_dir and vfs_rename_other checks d_mountpint with the
    >> target->i_mutex, new_dir->i_mutex, and old_dir->i_mutex held.
    >> Therefore the guarantees in 3.12 are:
    >> - unlink versus mount races are prevented by the
    >> dentry->d_inode->i_mutex of the dentry being removed.
    >> - unlink versus umount races are uninteresting.
    >> - mount versus rename races in testing of d_mountpoint are ignored.
    > Read what you've written a few lines above. The part about target->i_mutex
    > being held.

    That works for the rename as unlink case but we don't hold
    old_dentry->d_inode->i_mutex which is what is needed to prevent a mount
    on the dentry we are renaming.

    >> So comparing this to how I have implemented covered the test is at a
    >> slightly different location in the call path so there may be a slightly
    >> larger race in rename.
    > You've got a race in unlink. You've got a race in rename. You've got a race
    > in rmdir. And none of those had that race in 3.12 (including rename()).

    Rename absolutely has a race in 3.12. With very lucky timing it is
    possible to mount something on directory a, simultaneously rename
    a to b, and have the mount show up on b.

    > BTW, could you describe the races with umount in a bit more details? Races
    > with mount are simple - rmdir() sees that victim isn't a mountpoint and
    > proceeds, mount() sees that victim is still alive and proceeds, despite
    > the fact that victim is irretrievably on the way to removal. And that's
    > what ->i_mutex on victim prevents, making "check for d_mountpoint / remove /
    > call dont_mount()" atomic wrt mount(). What is the problem you are seeing
    > with umount()? rmdir() getting EBUSY because it hasn't noticed umount()
    > happening in parallel with it? Legitimate behaviour, as far I can see...
    > Or is it about something different?

    I did not say it was a problem only that it was a race. The only case I
    can see is getting a state EBUSY, and I see no problem with a that.


     \ /
      Last update: 2013-11-08 23:41    [W:3.170 / U:0.812 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site