netdev - Re: getting rid of ->splice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 5 Nov 2014 23:55:23 -0800
From:	Christoph Hellwig <hch@...radead.org>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: getting rid of ->splice_write?

On Wed, Nov 05, 2014 at 06:49:45PM +0000, Al Viro wrote:
> Not really.  A minor nitpick is that you've missed port_fops_splice_write(),
> but the real bitch isn't that and not even the sockets (see the fun with
> iov_iter sendmsg/recvmsg work getting resurrected).  It's that NULL
> ->splice_write() means default_file_splice_write.  IOW, you'd need either
> ->write_iter() for _everything_ (with support of bvec-backed ones included,
> since that's what iter_file_splice_write() will feed to ->write_iter()),
> or you need to have do_splice_from() check if ->write_iter is NULL and
> go for default_file_splice_write() instead of iter_file_splice_write().
> 
> The latter might be doable, but the former is really over the top - for
> that we'd need to touch every driver instance of ->write() out there.
> You want to do that, it's your funeral...

The latter is what I thought off.  And yes, the socket work looks good,
especially if we can get rid of ->sendpage as well.  That'll require
passing new flags somewhere, the ones in the iocb added for
preadv2/pwritev2 might be usable.

> > Similarly it seems to be like we could kill ->splice_read by
> > implementing an equivalent iteration over ->read_iter.
> 
> Hard to do.  I agree that we want to, but it'll take quite a bit of work
> on iov_iter primitives, I'm afraid.  At the very least, we want a variant
> of iov_iter that could steal pages.  Don't forget that a large part of
> the rationale behind splice_read was the ability to play zero-copy games.
> 
> I'm not sure if it will happen this cycle; there's more than enough fun
> on the net/* side.  _If_ that ends up done faster than I expect it to be,
> ->splice_read() is the obvious next target.

And zero copy games would become a lot less nasty if they could go
straight through ->read_iter instead of the current abuses of splice
infrastructure.

Same for sendfile, btw.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html