Messages in this thread | | | Date | Mon, 25 Jun 2012 14:53:57 +0100 | From | Al Viro <> | Subject | Re: deferring __fput() |
| |
On Mon, Jun 25, 2012 at 03:19:56PM +0200, Peter Zijlstra wrote:
> > I'll need to reread that thread to comment on the specifics (had been too long ago; I don't > > remember the details), but... See Linus' objections to full-async fput() circa this April > > or March. There's a reason why this patchset uses task_work_add() whenever possible. > > Ok, I'll try and find that thread, so the advantage of task_work_add() > is that you'll keep the work in the task that caused it wherever > possible, right -- provided its actually sitll around. > > If we make fput() deferable in general we'll be sure to grow some 'fun' > cases. So are we going to add a sync against unmount someplace to avoid > these un-expected -EBUSY things?
No. We are not. And I don't care how tasty some application might be - this way madness lies. If you have _anything_ doing async fput() (which is perfectly possible with the current mainline), you have to live with the fact that yes, filesystem will be busy while your mechanism, whatever it might be, is in use.
BTW, you do realize that delayed fput() may mean delayed fs shutdown? Think of umount -l while you have an opened file...
| |