From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra13.linbit.com (zimbra.linbit.com [212.69.161.123]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail09.linbit.com (LINBIT Mail Daemon) with ESMTPS id 703C11056444 for ; Wed, 4 May 2016 14:52:54 +0200 (CEST) Date: Wed, 4 May 2016 14:52:53 +0200 From: Lars Ellenberg To: Nicolas Dichtel Message-ID: <20160504125253.GP16459@soda.linbit> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5729EFBC.7040002@6wind.com> Content-Transfer-Encoding: quoted-printable Cc: netdev@vger.kernel.org, drbd-dev@lists.linbit.com, David Miller , linux-kernel@vger.kernel.org, philipp.reisner@linbit.com Subject: Re: [Drbd-dev] [PATCH net-next v2] block/drbd: use nla_put_u64_64bit() List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, May 04, 2016 at 02:49:00PM +0200, Nicolas Dichtel wrote: > Le 04/05/2016 11:05, Lars Ellenberg a =E9crit : > [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 head= er 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. Yes. Which in our case is not a problem. But I don't object to the padding per se, if that is how things "should be". I try to understand why you so much object to using 0 as pad. Lars From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753262AbcEDMxA (ORCPT ); Wed, 4 May 2016 08:53:00 -0400 Received: from zimbra13.linbit.com ([212.69.166.240]:51776 "EHLO zimbra13.linbit.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753039AbcEDMw6 convert rfc822-to-8bit (ORCPT ); Wed, 4 May 2016 08:52:58 -0400 Date: Wed, 4 May 2016 14:52:53 +0200 From: Lars Ellenberg To: Nicolas Dichtel Cc: David Miller , netdev@vger.kernel.org, philipp.reisner@linbit.com, drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org Subject: Re: [Drbd-dev] [PATCH net-next v2] block/drbd: use nla_put_u64_64bit() Message-ID: <20160504125253.GP16459@soda.linbit> Mail-Followup-To: Nicolas Dichtel , David Miller , netdev@vger.kernel.org, philipp.reisner@linbit.com, drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5729EFBC.7040002@6wind.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 04, 2016 at 02:49:00PM +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. Yes. Which in our case is not a problem. But I don't object to the padding per se, if that is how things "should be". I try to understand why you so much object to using 0 as pad. Lars From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Ellenberg Subject: Re: [PATCH net-next v2] block/drbd: use nla_put_u64_64bit() Date: Wed, 4 May 2016 14:52:53 +0200 Message-ID: <20160504125253.GP16459@soda.linbit> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org, David Miller , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, philipp.reisner-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org To: Nicolas Dichtel Return-path: Content-Disposition: inline In-Reply-To: <5729EFBC.7040002-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org Errors-To: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org List-Id: netdev.vger.kernel.org On Wed, May 04, 2016 at 02:49:00PM +0200, Nicolas Dichtel wrote: > Le 04/05/2016 11:05, Lars Ellenberg a =E9crit : > [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 al= igned > 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. Yes. Which in our case is not a problem. But I don't object to the padding per se, if that is how things "should be". I try to understand why you so much object to using 0 as pad. Lars