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: <20120105.123448.22028378936304397.davem@davemloft.net>
Date:	Thu, 05 Jan 2012 12:34:48 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	David.Laight@...LAB.COM
Cc:	Ian.Campbell@...rix.com, netdev@...r.kernel.org,
	eric.dumazet@...il.com
Subject: Re: [PATCH 0/6 v2] skb paged fragment destructors

From: "David Laight" <David.Laight@...LAB.COM>
Date: Thu, 5 Jan 2012 17:27:31 -0000

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

TCP breaks already if a driver defers indefinitely.  All drivers
absolutely must perform TX reclaim in a small, finite, amount of
time.

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

This isn't the Mentat stack... so it's extremely unwise to try and
match up concerns you've had in that stack over here when evaluating
changes to Linux.
--
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