On Wed, 2016-05-04 at 14:49 +0200, Nicolas Dichtel wrote: > Le 04/05/2016 11:05, Lars Ellenberg a écrit : > [snip] > > We don't have an "alignment problem" there, btw. > > Last time I checked, we did work fine without this alignment magic, > > we already take care of that, yes, even on affected architectures. > The code adds several consecutive u64 attributes. The nl attribute header is 4 > bytes, thus the full attribute length is 12 bytes. If the first u64 is aligned > on 8 (nla_data()), the next one is not aligned on 8: it starts 12 bytes (8 > (u64) > + 4 (nl attr hdr)) after the previous u64.
As I mentioned earlier ( https://lkml.org/lkml/2016/4/22/706 ), if both kernel and user land do not blindly use *(u64 *)ptr to put/get these values, there was no issue. kernel was fine, and most user land apps were fine as well. Only for compound struct like tcp_info this was nice to get alignment for performance reason (it removed one memcpy(), or the use of put_unaligned() helpers)
