On Mon, Nov 03, 2014 at 08:22:07AM +0800, Herbert Xu wrote: > On Mon, Nov 03, 2014 at 12:16:34AM +0000, Al Viro wrote: > > > > NAK with extreme prejudice. The right way to deal with that is > > to convert the socket side of things to iov_iter. And give it a > > consistent behaviour, while we are at it (some protocols do advance > > the damn thing, so do not). There are _very_ good reasons to have those > > iovecs unchanged - if you look at the callers on the socket side, you'll > > see a bunch that has to _copy_ iovec just to avoid it being buggered. > > And you get rather suboptimal behaviour in memcpy_fromiovec() and friends, > > exactly because you have to skip through the emptied elements. > > > > IOW, no way in hell. > > You're welcome to send patches fix every spot in the network stack > that writes to the iovec. But until the network stack is all fixed > up, having a const struct iovec in aio_read/aio_write is a delusion.
Check how many ->aio_read() and ->aio_write() instances are left. If you are implying that dealing with the ones in net/* is not feasible, I invite you to check the situation in fs/*, where we used to have quite a few. Compare it with what used to be there in e.g. January. Note, BTW, that there's a damn good reason to convert the socket side of things to iov_iter - as it is, ->splice_write() there is basically done with page-by-page mapping and doing kernel_sendmsg(); being able to deal with "map and copy" stuff *inside* ->sendmsg() would not only reduce the overhead, it would allow to get rid of ->sendpage() completely. Basically, let ->sendmsg() instances check the iov_iter type and play zerocopy games if it's an "array of kernel pages" kind. Compare ->sendpage() and ->sendmsg() instances for the protocols that have nontrivial ->sendpage(); you'll see that there's a lot of duplication. Merging them looks very feasible, with divergence happening only very deep in the call chain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/