[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1462372026.5535.344.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Wed, 04 May 2016 07:27:06 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: nicolas.dichtel@...nd.com
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
philipp.reisner@...bit.com, drbd-dev@...ts.linbit.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit()
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)
Powered by blists - more mailing lists