On Fri, Jan 29, 2016 at 3:04 PM, Sowmini Varadhan <sowmini.varad...@oracle.com> wrote: > On (01/29/16 15:00), Tom Herbert wrote: > >> The sparc documentation is pretty clear >> http://docs.oracle.com/cd/E19253-01/816-4854/hwovr-2/index.html, seems >> like unaligned accesses are not allowed in the architecture. > > yes, but looks like you can paper over some of this with > memcpy (as was happening with the saddr ref in skb_flow_dissect > that puzzled me and Eric because it did not generate any traps). > Well, I am more worried about what happens when an unaligned encapsulated TPC/IP packet gets into the stack. It seems unlikely we'd want to replace a bunch of address, seq numbers, etc. with memcpy all over the stack. ;-)
But even within flow dissector, to be completely correct, we need to replace all 32-bit accesses with the mempy (flow_label, mpls label, keyid) and be vigilant about new ones coming in. For that matter, if we really want to be pedantic, nothing prevents a driver from giving us a packet with 1 byte alignment in which case we need to consider access to 16-bit values also! Considering that this is a very narrow use case (requires encapsulated Ethernet and architecture that is alignment sensitive), I wonder if we should just punt on flow dissection when we see non 4-byte alignment and CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not set. Tom
