lkml.org 
[lkml]   [2014]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Detaching mounts on unlink for 3.15
    On Sun, Apr 20, 2014 at 06:41:08AM +0100, Al Viro wrote:
    > <do task_work_add or schedule_delayed_work song and dance>
    > right in the end of mntput_no_expire(). OK, now I have something that
    > looks like a complete solution. The last missing bit is to take all
    > filp_close() of acct->file to kernel thread, and have them done via
    > __fput_sync() there. Then auto-close (done from cleanup_mnt()) will
    > consist of shutting down all affected acct and waiting for that kernel
    > thread to run through everything currently in its queue. That'll take
    > care of waiting until acct(NULL) done by somebody else gets through closing
    > the file and through corresponding mntput(). And *those* mntput() also
    > can be synchronous - they are clones of the one we hadn't finished shutting
    > down yet, so both dput() and deactivate_super() will bugger off immediately.
    > So we just mark those instead-of-mnt_pin() clones as MNT_INTERNAL. Voila.
    > After that ->mnt_pinned crap dies, acct auto-close ought to be race-free
    > and we get the actual fs shutdown guaranteed to be on shallow stack, without
    > extra context switches, etc. in the normal case.

    Sigh... It's really messy.
    All versions since lazy fput introduction have acct_auto_close()
    doing the wrong thing on r/o remount of superblock; we want the damn file
    closed *before* we go further than acct_auto_close(). Worse, we are
    holding ->s_umount there, so any kind of waiting would have to be very
    careful to avoid deadlocks. What's more, prevention of open for write
    hits acct_auto_close(), so even if we wait there, we still have a window
    when new acct file could be opened and not auto-closed.
    All versions have problems with acct_process() in the middle of
    umount(); originally it was a blatant call of ->write() happening without
    any regard for file getting closed, then it was file getting written to
    and closed in the middle of fs shutdown, then - write/close capable of
    pushing fs shutdown past the return from umount(2).
    All versions have problems with acct(NULL) vs. umount - the latter
    does not wait for the former. Eric's patches plug that one, but there's
    a serious deadlock potential.

    Who the hell had thought that auto-close was a good thing to have? Neither
    BSD (where the whole thing originated) nor original Linux implementation
    did that - umount /var while accounting was turned on would simply say
    that /var was busy and fail... And no, simply ripping that idiocy out
    won't fly - while Debian has /etc/init.d/acct stop turning the sucker off,
    Fedora psacct doesn't do anything of that sort and relies on auto-close
    instead, so getting rid of auto-close will lead to such boxen failing to
    unmount /var on shutdown ;-/


    \
     
     \ /
      Last update: 2014-05-11 19:21    [W:4.083 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site