[lkml]   [2012]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] vfs: Do not allow mnt_longterm to go negative
    On Tue, May 29, 2012 at 12:56:44PM +0200, Luk?? Czerner wrote:
    > Anyone can take a look at this ? It's pretty pressing I would say
    > since this bug will not only disallow to unattach the loop devices
    > but also make it unable to actually unmount the file system!

    I agree that it's a bug, but I don't believe that this is a proper
    fix. We can do it much simpler. Look: making these guys longterm
    happens exactly at the same points where we set their ->mnt_ns non-NULL.
    Remember that "longterm" == "internal kernel mount, mount in some
    namespace, someone's root or pwd". So the problem is that umount_tree()
    is that umount_tree() blindly assumes that it's killing a longterm
    ref, even though it may be called when dissolving a tree that never
    made it into anyone's namespace. Fine, so let's just have that
    sucker do
    if (p->mnt_ns)
    p->mnt_ns = NULL;
    instead and that's all it takes. Alternatively, we can just turn the
    code in mntput_no_expire() into
    if (likely(mnt->mnt_ns || atomic_read(...))
    and get rid of longterm/shortterm logics around ->mnt_ns completely.
    Short-term, pardon the bad pun, I'm going with the first variant; it's
    less intrusive. Longer term I think we want to get rid of playing with
    mnt_longterm in there and just check ->mnt_ns as well when deciding to
    go for the fast path in mntput_no_expire().

    Fixed in my tree, will push in a couple of hours. And that'll need to
    go into -stable as well. Thanks for catching that sucker...

     \ /
      Last update: 2012-05-30 04:41    [W:0.022 / U:43.160 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site