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:0.198 / U:2.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site