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 ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
