netdev - RE: [PATCH 0/6 v2] skb paged fragment destructors

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6D8AF35@saturn3.aculab.com>
Date:	Thu, 5 Jan 2012 17:27:31 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Ian Campbell" <Ian.Campbell@...rix.com>,
	"David Miller" <davem@...emloft.net>
Cc:	<netdev@...r.kernel.org>, "Eric Dumazet" <eric.dumazet@...il.com>
Subject: RE: [PATCH 0/6 v2] skb paged fragment destructors

 
> The mail at [0] contains some more background and rationale but
> basically the completed series will allow entities which inject pages
> into the networking stack to receive a notification when the stack has
> really finished with those pages (i.e. including retransmissions,
> clones, pull-ups etc) and not just when the original skb is finished
> with, which is beneficial to many subsystems which wish to inject
pages
> into the network stack without giving up full ownership of those
page's
> lifecycle. It implements something broadly along the lines of what was
> described in [1].

If you are doing that, then the network drivers must ensure they
free such skb as soon as the transmit completes - rather than
deferring the 'end of tx' processing until some later time.

Without that the sending code can't reuse the 'page' for another
request - which is one of the things I presume this allows.

(We had issues with this on SVR4 with STREAMS buffers allocated
with esballoc()...)

	David


--
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