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: <5315FBAA.3030809@mellanox.com>
Date:	Tue, 4 Mar 2014 18:13:30 +0200
From:	Or Gerlitz <ogerlitz@...lanox.com>
To:	David Miller <davem@...emloft.net>,
	Joseph Gasparakis <joseph.gasparakis@...el.com>,
	Pravin B Shelar <pshelar@...ira.com>
CC:	<hkchu@...gle.com>, <edumazet@...gle.com>,
	<netdev@...r.kernel.org>, Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH] net-gre-gro: Fix a bug that breaks the forwarding path

On 28/02/2014 23:56, David Miller wrote:
> The topic of the skb->encapsulation semantics has come up several 
> times in the past few weeks. We cannot move forward on any changes in 
> this area until the semantics are well defined, and documented. Can 
> someone work on a patch which documents skb->encapsulation properly, 
> and then we can come back to fixing this bug? Thanks. 

Lets try... the skb->encapsulation flag was introduced and used in 3.8 
by the
sequence of these three commits

0afb166 vxlan: Add capability of Rx checksum offload for inner packet
d6727fe vxlan: capture inner headers during encapsulation
6a674e9 net: Add support for hardware-offloaded encapsulation

When discussed earlier on the list in the context of the skb->ip_summed 
field,
Tom Herbert came with the following interpretation for the semantics 
which Joseph confirmed

"when skb->encapsulation is set the ip_summed is valid for both the inner and outer header
(e.g. CHECKSUM_COMPLETE is always assumed okay for both layers). If skb->encapsulation is not set then ip_summed is only valid for outer header"

As for the TX side of things, the change-log of commit 6a674e9 states

"For Tx encapsulation offload, the driver will need to set the right bits in netdev->hw_enc_features. The protocol driver will have to set the skb->encapsulation bit and populate the inner headers, so the NIC driver will use those inner headers to calculate the csum in hardware."

So in higher level, it seems that the role of the skb->encapsulation field is to mark the skb to carry encapsulated packet for the code path between the time the packet is encapsulated by the protocol driver (e.g vxlan/ipip) to the time driver xmit is called. Or from the time driver rx code runs till the the time the packet is decapsulated.

Further, my personal interpretation was that on the rx path, skb should carry the encapsulation flag **only** if the HW was able to offload the inner checksum.

Joseph, what's your thinking here?

Or.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ