netdev - Re: can we reuse an skb

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20090619.162957.156347025.davem@davemloft.net>
Date:	Fri, 19 Jun 2009 16:29:57 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rick.jones2@...com
Cc:	radhamohan_ch@...oo.com, netdev@...r.kernel.org
Subject: Re: can we reuse an skb

From: Rick Jones <rick.jones2@...com>
Date: Fri, 19 Jun 2009 09:56:06 -0700

> Assuming a driver did have its own "pool" and didn't rely on the
> pool(s) from which skbs are drawn, doesn't that mean you have to now
> have another configuable?  There is no good guarantees on when the
> upper layers will be finished with the skb right?  Which means you
> would be requiring the admin(s) to have an idea of how long their
> applications wait to pull data from their sockets and configure your
> driver accordingly.
> 
> It would seem there would have to be a considerable performance gain
> demonstrated for that kind of thing?

Applications can hold onto such data "forever" if they want to.

Any scheme which doesn't allow dynamically increasing the pool
is prone to trivial DoS.
--
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