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>] [day] [month] [year] [list]
Message-ID: <49C18C24.6000601@goop.org>
Date:	Wed, 18 Mar 2009 17:04:52 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Vladislav Bolkhovitin <vst@...b.net>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Using splice to carry Xen granted pages through the network stack?

Hi Jens,

In a thread from December last year ("Support for zero-copy TCP transmit 
of user space data") you suggested using the splice machinery as a way 
to implement zero-copy transmit for iscsi data.

I have a similar problem relating to doing zero-copy transmit of pages 
granted from another Xen domain.  These are pages which are in some ways 
similar to device mappings (they have no struct page unless we jump 
through some hoops to give them one, for example) which are given to us 
by another domain (virtual machine)'s network stack since they contain 
data they want to transmit through our stack.  Once the stack has 
finished with the pages we need to get them back to return to the 
original domain (and definitely not let them get freed into the normal 
kernel pool).

I've been looking a little bit at the splice stuff to work out how it 
might be useful in this case.  One issue struct page; I guess we really 
can't get away from having one for granted pages and still get the full 
value of using splice (especially I can see also see it being useful on 
the block side of the world as well).  So, we can jump through hoops for 
that.

But the general plumbing of splice into the network stack seems to have 
been an open issue since you introduced it 3 years ago (using as a 
reference http://lwn.net/Articles/181169/).  Has any work been done on 
this aspect since?  What would need to be done to do it?  Would it mean 
wiring up a pipe_buffer_operations to operate with something like 
Rusty's skb_shared_info destructor?

Thanks,
    J
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ