On Fri, Jan 29, 2016 at 1:09 PM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (01/29/16 13:00), Tom Herbert wrote: >> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't >> those create alignment issues (like when stack looks at addresses)? > > They do. > > http://comments.gmane.org/gmane.linux.network/370672 > > some of it was fixed in https://lkml.org/lkml/2015/7/20/63. > There's still some NET_IP_ALIGN missing. IIRC, I was seeing > this for mldv3, but the fix has to be done carefully, by > someone who knows how to fully regression test it. > > I dont know if other tunneling methods manage to get the > NET_IP_ALIGN correct in every case. > Fortunately, most encapsulations are based on 4-byte alignment. ETHER_IP even specifies a two byte header to ensure that whatever follows the encapsulated Ethernet header is 4-byte aligned. The encapsulation protocols that carry Ethernet without any inserted bytes for alignment are the potential problem (GRE, VXLAN, etc.). NET_IP_ALIGN can't help because the outer and inner (IP) headers have different alignment, so no one value can work.
> Also, while sparc complains about unaligned access > in most cases, some sins may pass under the radar, and other > platforms dont even generate traps, so it's easy to not know > that there's a problem, a lot of the time. > That is worrisome. The only way I can think of to be completely protected would be to copy encapsulated Ethernet frames to NET_IP_ALIGN buffer in the driver :-( It doesn't look like VXLAN does anything like that. Tom > --Sowmini >
