From: Edward Cree <ec...@solarflare.com> Date: Wed, 17 May 2017 15:00:04 +0100
> On 16/05/17 23:53, Alexei Starovoitov wrote: >> following this line of thinking it feels that it should be possible >> to get rid of 'aux_off' and 'aux_off_align' and simplify the code. >> I mean we can always do >> dst_reg->min_align = min(dst_reg->min_align, src_reg->min_align); >> >> and don't use 'off' as part of alignment checks at all. > Problem with this approach, of course, is that (say) NET_IP_ALIGN + > sizeof(ethhdr) = 16 is muchly aligned, whereas if you turn all > constants into alignments you think you're only 2-byte aligned. > I think you have to track exact offsets when you can, and only turn > into an alignment when you introduce a variable. > Of course it can still be fooled by e.g. 2 + (x << 2) + 14, which it > will think is only 2-aligned when really it's 4-aligned, but unless > you want to start tracking 'bits known to be 1' as well as 'bits > known to be 0', I think you just accept that alignment tracking > isn't commutative. The obvious cases (ihl << 2 and so) will work > when written the obvious way, unless the compiler does something > perverse. > OTOH the 'track known 1s as well' might work in a nice generic way > and cover all bases, I'll have to experiment a bit with that. Both cases are common in real BPF programs. The offsets really are necessary. It's funny because initially I tried to implement this without the auxiliary offset and it simply doesn't work. :-) We always have to track when you've seen the offset that cancels out the NET_IP_ALIGN. And as stated it can occur both before and after variable offsets have been introduced. You have to catch both: ptr += variable; ptr += 14; and: ptr += 14; ptr += variable; /* align = 4 */ And always see at the end that "NET_IP_ALIGN + offsets" will be properly 4 byte aligned.