[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120625135357.GV14083@ZenIV.linux.org.uk>
Date: Mon, 25 Jun 2012 14:53:57 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
". James Morris" <jmorris@...ei.org>,
linux-security-module@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
David Miller <davem@...emloft.net>
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...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists