Re: deferring __fput()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sat, Jun 23, 2012 at 10:01:41PM +0100, Al Viro wrote:
> On Sat, Jun 23, 2012 at 10:38:00PM +0200, Oleg Nesterov wrote:
> 
> > > Matter of fact, it would become identical to struct rcu_head
> > > after that...
> > 
> > This is not clear to me... Why this is good?
> 
> Occam's Razor.
> 
> > I understand that sizeof(task_work) == sizeof(rcu_head) would be
> > nice, probably you meant just this?
> 
> More than that - the callback type is also the same (pointer to such
> struct -> void).  IOW, they both look like two instances of the
> same thing ("list of callbacks"), differing only in what and
> when does calling.

BTW, I suspect that we really want to move exit_task_work() down past the
calls of exit_mm()/exit_files() (and lose the PF_EXITING check in
task_work_add(), making that ordering responsibility of callers).  It's
not strictly necessary - we can just treat PF_EXITING the same way we
treat PF_KTHREAD, but that means driving those final fput on exit through
schedule_work().  Extra context switch...

I'm not 100% sure about that one - if you have planned task_work users
relying on e.g. task->mm still being there when callback runs, we obviously
can't go that way, but it would be nice to have.  AFAICS, existing users are
fine with such reordering.

We could, in principle, add a "ok_late" argument, allowing to add after
PF_EXITING has been set only if it's true and run the list twice, but
that's really more convoluted than I would like...

Comments?