From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752292AbcEDO1N (ORCPT ); Wed, 4 May 2016 10:27:13 -0400 Received: from mail-pf0-f178.google.com ([209.85.192.178]:35732 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbcEDO1M (ORCPT ); Wed, 4 May 2016 10:27:12 -0400 Message-ID: <1462372026.5535.344.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit() From: Eric Dumazet To: nicolas.dichtel@6wind.com Cc: David Miller , netdev@vger.kernel.org, philipp.reisner@linbit.com, drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org Date: Wed, 04 May 2016 07:27:06 -0700 In-Reply-To: <5729EFBC.7040002@6wind.com> References: <57286F49.8050107@6wind.com> <1462268358-19044-1-git-send-email-nicolas.dichtel@6wind.com> <20160503100644.GE16459@soda.linbit> <20160503.120556.1317913903199470646.davem@davemloft.net> <20160504090529.GJ16459@soda.linbit> <5729EFBC.7040002@6wind.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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)