netdev - Re: Multicast/Broadcast enhancement: SKB read-only with copy-on-write

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

Date:	Mon, 04 Mar 2013 08:28:06 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yannick Koehler <yannick@...hler.name>
Cc:	netdev@...r.kernel.org
Subject: Re: Multicast/Broadcast enhancement: SKB read-only with
 copy-on-write

On Mon, 2013-03-04 at 10:29 -0500, Yannick Koehler wrote:
> Hi,
> 
>   Recently I was working into the kernel area where the code handle
> broadcast/multicast in bridge logical interface for example.  It seems
> today inevitable that when we flood, the bridge code has to duplicate
> the full SKB, metadata as well as data, in order to transmit to each
> link under it.  I was wondering if there was way for the SKB system to
> support copy-on-write, such that, from a starting point, the SKB would
> be "frozen" into a read-only mode and then if someone wants to modify
> the SKB metadata/data it is done in a way to preserve the original SKB
> memory, as to ensure that after the SKB has been transmitted over that
> particular link, it can also be used without a full memory copy to be
> sent to subsequent link, simultaneously on multi-core/mutli-interface
> system.
> 
>   I am wondering at what level such work would be consider, is it
> relatively easy, does Linux have anything like that, is it major work,
> since pretty much everyone expect SKB data to be writable (like
> skb_may_pull could be used to obtain a specific client SKB version
> area).  It would probably require a new field in the SKB to indicate
> that this is a read-only/copy-on-write version of a specific "original
> SKB".
> 
>   Anyway, just wanted some thoughts/opinions on the topic regarding
> the scale of such a change.
> 

Current skb handling already provides this "read-only" and
"copy-on-write" management.

We only have to use the correct API where it matters, like
skb_share_check()

For an example, take a look at commit de063b7040dcd9
(bonding: remove packet cloning in recv_probe())

ARP packets for example could be handled in a read-only way.

(You dont really explain what particular problem you have,
ARP is only a guess...)



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