On Fri, Apr 18, 2014 at 01:37:26AM +0100, Al Viro wrote: > IOW, workqueue is not the right tool here. OTOH, it looks like we do have > a problem with kernel/acct.c vs. umount; it just requires a race between > auto-closing and acct_process_in_ns(). It's narrow, so it doesn't bite > us all the time, but it's there... Damn, it had been a long time since > I really looked at that code ;-/ > > Actually, there's another reason why workqueue is bogus - we call > do_acct_process(), same as we do on acct(NULL) (which might or might > not be a good idea), but at least with do that from the context of > real process doing umount(2). Doing that from workqueue is going to > produce a really bogus record... Egads... Why the hell are we forming (almost) the same record again and again for every pidns the process belongs to? Sure, we want pid/ppid/uid/gid munged, but the rest of it? And there's something else wrong here - what happens if the last process in a namespace where we have accounting going on just plain exits? All mounts in that namespace get dissolved. Which leads to acct being autoclosed. From the context of a process that already has done acct_process(). Do we ever want to write an acct record on autoclose-on-umount? Do we want that record of umount(8) we would've missed otherwise (along with those of all other still living processes - those we *will* miss anyway)? Linus, do you have objections against dropping that behaviour? In theory, some tools might look at the last record in acct file to figure out what has stopped the sucker (accton vs. umount), so it's a user-visible change, but... -- 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
