On Thu, Sep 08, 2016 at 04:39:34PM -0400, CAI Qian wrote:
>
>
> ----- Original Message -----
> > From: "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > To: "CAI Qian" <caiqian@xxxxxxxxxx>
> > Cc: "Dave Chinner" <david@xxxxxxxxxxxxx>, "Al Viro"
> > <viro@xxxxxxxxxxxxxxxxxx>, "linux-xfs"
> > <linux-xfs@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
> > Sent: Thursday, September 8, 2016 2:01:23 PM
> > Subject: Re: xfs_file_splice_read: possible circular locking dependency
> > detected
> >
> > On Thu, Sep 8, 2016 at 8:29 AM, CAI Qian <caiqian@xxxxxxxxxx> wrote:
> > > Right. FYI, revert the commit below fixes the regression,
> > >
> > > 8d02076 : ->splice_write() via ->write_iter()
> >
> > I guess you didn't actually revert that, because so much else has
> > changed. So you just tested the pre- and post- state of that commit?
> Right, I just reverted that commit while that one is as a HEAD. It is
> not going to be a straight-forward revert. There have had a few commits
> on the top already, so there will be some additional work to bake a proper
> revert to the current origin HEAD.
>
> Though, Everything else looks straigtforward (PAGE_CACHE_* conversion,
> inode_lock* conversion, file_remove_privs() converstion). It seems only
> tricky thing is that generic_write_sync() starts to use struct kiocb *
> instead of struct file *, so generic_file_splice_write() and probably
> xfs_file_splice_write() need to change to use kiocb as well.
Don't bother. You'll just hit a different lockdep issue - a locking
order problem on the write side. I tried to get that fixed years
ago:
https://lkml.org/lkml/2011/7/18/4
http://oss.sgi.com/archives/xfs/2011-08/msg00122.html
http://oss.sgi.com/archives/xfs/2012-11/msg00671.html
That specific problem was fixed by the above write_iter
infrastructure fixes, but introduced the read side problem. i.e.
splice has /always/ had locking order issues that XFS exposed.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|