netdev - Re: [PATCH net-next] packet: allow to transmit +4 byte in TX

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]

Message-Id: <20140228.165234.200477519056803957.davem@davemloft.net>
Date:	Fri, 28 Feb 2014 16:52:34 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	dborkman@...hat.com
Cc:	netdev@...r.kernel.org, mathias.kretschmer@...us.fraunhofer.de,
	greearb@...delatech.com, phil@....cc
Subject: Re: [PATCH net-next] packet: allow to transmit +4 byte in TX_RING
 slot for VLAN case

From: Daniel Borkmann <dborkman@...hat.com>
Date: Fri, 28 Feb 2014 02:22:06 +0100

> Commit 57f89bfa2140 ("network: Allow af_packet to transmit +4 bytes
> for VLAN packets.") added the possibility for non-mmaped frames to
> send extra 4 byte for VLAN header so the MTU increases from 1500 to
> 1504 byte, for example.
> 
> Commit cbd89acb9eb2 ("af_packet: fix for sending VLAN frames via
> packet_mmap") attempted to fix that for the mmap part but was
> reverted as it caused regressions while using eth_type_trans()
> on output path.
> 
> Lets just act analogous to 57f89bfa2140 and add a similar logic
> to TX_RING. We presume size_max as overcharged with +4 bytes and
> later on after skb has been built by tpacket_fill_skb() check
> for ETH_P_8021Q header on packets larger than normal MTU. Can
> be easily reproduced with a slightly modified trafgen in mmap(2)
> mode, test cases:
> 
>  { fill(0xff, 12) const16(0x8100) fill(0xff, <1504|1505>) }
>  { fill(0xff, 12) const16(0x0806) fill(0xff, <1500|1501>) }
> 
> Note that we need to do the test right after tpacket_fill_skb()
> as sockets can have PACKET_LOSS set where we would not fail but
> instead just continue to traverse the ring.
> 
> Reported-by: Mathias Kretschmer <mathias.kretschmer@...us.fraunhofer.de>
> Signed-off-by: Daniel Borkmann <dborkman@...hat.com>

Looks good, applied, thanks Daniel.
--
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