Re: linux-next: manual merge of the block tree with the vfs tree

[Al Viro]

On Thu, Jan 29, 2015 at 05:15:55AM +0000, Al Viro wrote:
> On Wed, Jan 28, 2015 at 06:11:02PM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 27, 2015 at 04:54:22AM +0000, Al Viro wrote:
> > > I don't mind opening a never-rebased branch for generic iov_iter-related stuff;
> > > if you prefer to handle it that way - just tell.  The first two patches
> > > from that series would definitely go there; as for the rest... no preferences
> > > here.
> > 
> > It might make sense to just keep the VFS patches in your tree.
> > The target ones also are something I'd prefer if it goes through Nic
> > with additional review.  In addition they aren't really critical,
> > so if you merge the prep patches now we can feed the rest through
> > the proper trees in the .21 merge window.
> 
> Done.  The first two are in #iov_iter now (merged into #for-next), the
> rest is dropped.  And #iov_iter is in never-rebased mode, so feel free
> to pull it wherever you need it.

FWIW, there's an interesting question about the second commit in there -
what do we want vfs_iter_{read,write}() to do with *iter in case if it
has hit this:
        if (ret == -EIOCBQUEUED)
                ret = wait_on_sync_kiocb(&kiocb);

Do we require ->read_iter() and ->write_iter() on sync kiocb to do all
advancing the iter before returning -EIOCBQUEUED?  What's more, do we
ever want to have it returned on sync kiocb?  IOW, is there any point
in having that wait in callers?

Note that there are _very_ few drivers that ever do that; fs/direct_io.c,
for example, will wait for completion in case of sync kiocb.  AFAICS,
there are exactly two drivers like that: drivers/usb/gadget/legacy/inode.c
and drivers/usb/gadget/function/f_fs.c.  And the latter is very easy to
convert to "waits in case of sync kiocb" - there already are two codepaths
({read,write} and aio_{read,write}) and it's trivial to teach the sync
path to deal with arbitrary iov_iter, with aio side of things doing the
sync variant in case of sync kiocb.  Cheaper, as well, since we don't need
to copy iovec, etc.

I'm not sure if ep_io() and ep_aio_rwtail() + wait for completion are
eqiuvalent; ep_read/ep_write are very easy to turn into sync side of
->read_iter/->write_iter and if that's equivalent to ep_aio_read/ep_aio_write
on sync kiocb + waiting for completion, we are fine.

Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/