On Wed, Mar 28, 2012 at 03:38:52AM +0100, Al Viro wrote:

On Tue, Mar 27, 2012 at 11:08:58PM +0200, Jan Kara wrote:

quoted

  Hello,

  maybe the name of this topic could be "How hard should be life of
filesystems?" but that's kind of broad topic and suggests too much of
bikeshedding. I'd like to concentrate on concrete possible pain points
between filesystems & VFS (possibly writeback or even generally MM).
Lately, I've myself came across the two issues in $SUBJECT:
1) dropping of last file reference can happen from munmap() and in that
   case mmap_sem will be held when ->release() is called. Even more it
   could be held when ->evict_inode() is called to delete inode because
   inode was unlinked.

Yes, it can.

quoted

2) since flusher thread takes inode reference when writing inode out, the
   last inode reference can be dropped from flusher thread. Thus inode may
   get deleted in the flusher thread context. This does not seem that
   problematic on its own but if we realize progress of memory reclaim
   depends (at least from a longterm perspective) on flusher thread making
   progress, things start looking a bit uncertain. Even more so when we
   would like avoid ->writepage() calls from reclaim and let flusher thread
   do the work instead. That would then require filesystems to carefully
   design their ->evict_inode() routines so that things are not
   deadlockable.

You mean "use GFP_NOIO for allocations when holding fs-internal locks"?

quoted

  Both these issues should be avoidable (we can postpone fput() after we
drop mmap_sem; we can tweak inode refcounting to avoid last iput() from
flusher thread) but obviously there's some cost in the complexity of generic
layer. So the question is, is it worth it?

I don't thing it is.  ->i_mutex in ->release() is never needed; existing
cases are racy and dropping preallocation that way is simply wrong.

The alternative to using ->release is ....?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>