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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 8 Jun 2007 09:48:24 +0200
From:	Jens Axboe <>
To:	Evgeniy Polyakov <>
Subject: Re: [PATCH][RFC] network splice receive

On Thu, Jun 07 2007, Evgeniy Polyakov wrote:
> On Thu, Jun 07, 2007 at 12:51:59PM +0200, Jens Axboe ( wrote:
> > > What bout checking if page belongs to kmalloc cache (or any other cache
> > > via priviate pointers) and do not perform any kind of reference counting
> > > on them? I will play with this a bit later today.
> > 
> > That might work, but sounds a little dirty... But there's probably no
> > way around. Be sure to look at the #splice-net branch if you are playing
> > with this, I've updated it a number of times and fixed some bugs in
> > there. Notably it now gets the offset right, and handles fragments and
> > fraglist as well.
> I've pulled splice-net, which indeed fixed some issues, but referencing
> slab pages is still is not allowed. There are at least two problems
> (although they are related):
> 1. if we do not increment reference counter for slab pages, they
> eventually get refilled and slab exploses after it understood that its
> pages are in use (or user dies when page is moved out of his control in
> slab).
> 2. get/put page does not work with slab pages, and simple
> increment/decrement of the reference counters is not allowed too.
> Both problems have the same root - slab does not allow anyone to 
> manipulate page's members. That should be broken/changed to allow splice
> to put its hands into network using the fastest way.
> I will think about it.

Perhaps it's possible to solve this at a different level - can we hang
on to the skb until the pipe buffer has been consumed, and prevent reuse
that way? Then we don't have to care what backing the skb has, as long
as it (and its data) isn't being reused until we drop the reference to
it in sock_pipe_buf_release().

Jens Axboe

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists