[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130319213831.GK21522@ZenIV.linux.org.uk>
Date: Tue, 19 Mar 2013 21:38:31 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Jan Kara <jack@...e.cz>
Cc: David Howells <dhowells@...hat.com>,
Miklos Szeredi <miklos@...redi.hu>,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, hch@...radead.org,
akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
neilb@...e.de, jordipujolp@...il.com, ezk@....cs.sunysb.edu,
sedat.dilek@...glemail.com, hooanon05@...oo.co.jp, mszeredi@...e.cz
Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules
On Tue, Mar 19, 2013 at 09:25:43PM +0100, Jan Kara wrote:
> > BTW, having sb_start_write() buried in individual ->splice_write() is
> > asking for trouble; could you describe the rules for that? E.g. where
> > does it nest wrt filesystem-private locks? XFS iolock, for example...
> Generally, the freeze protection should be the outermost lock taken (so
> that we mitigate possibility of blocking readers when waiting for fs to
> unfreeze). So it ranks above i_mutex, or XFS' ilock and iolock.
Welcome to deadlock, then:
xfs_file_splice_write()
...
xfs_ilock(ip, XFS_IOLOCK_EXCL);
...
ret = generic_file_splice_write(pipe, outfilp, ppos, count, flags);
> It seems that I screwed this up for ->splice_write() :-| If we are going to
> move out sb_start_write() out of filesystems' hands into do_splice_from()
> then we should likely do the same with ->aio_write(). Hmm?
Yes, I've a tentative patch doing just that; will push tonight.
--
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