From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtprelay.synopsys.com ([198.182.60.111]:60467 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932902AbeGIU2W (ORCPT ); Mon, 9 Jul 2018 16:28:22 -0400 Subject: Re: [PATCH v3] devres: Explicitly align datai[] to 64-bit References: <20180709134550.29541-1-abrodkin@synopsys.com> <20180709140717.GR2476@hirez.programming.kicks-ass.net> <20180709141056.GR2512@hirez.programming.kicks-ass.net> <44727d3cebda7bee5b68fb388bd2fecfc6dc7b89.camel@synopsys.com> <20180709144925.GU2476@hirez.programming.kicks-ass.net> <20180709152958.565weccfaktqauef@lakrids.cambridge.arm.com> <20180709153427.GY2476@hirez.programming.kicks-ass.net> <20180709154521.GS2512@hirez.programming.kicks-ass.net> <20180709154844.5p5yk34ezw2gbt3y@lakrids.cambridge.arm.com> From: Vineet Gupta Message-ID: Date: Mon, 9 Jul 2018 13:28:08 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: David Laight , 'Mark Rutland' , Peter Zijlstra Cc: Alexey Brodkin , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "linux-snps-arc@lists.infradead.org" , "stable@vger.kernel.org" , "greg@kroah.com" , "will.deacon@arm.com" , "gregkh@linuxfoundation.org" , "linux-arch@vger.kernel.org" , "geert@linux-m68k.org" Message-ID: <20180709202808.sp2sJ0TtZbqXA_dur4LFUgjYh6nWNo3CNOg9EwHOkHk@z> On 07/09/2018 09:10 AM, David Laight wrote: > From: Mark Rutland >> Sent: 09 July 2018 16:49 >> >> On Mon, Jul 09, 2018 at 05:45:21PM +0200, Peter Zijlstra wrote: >>> On Mon, Jul 09, 2018 at 05:34:27PM +0200, Peter Zijlstra wrote: >>>> On Mon, Jul 09, 2018 at 04:29:58PM +0100, Mark Rutland wrote: >>>>> Shouldn't that be 8? AFAICT, __alignof__(unsigned long long) is 8 on >>>>> x86_32: >>>> >>>> Curious, I wonder why we put that align in atomic64_32 then. >>> >>> Shiny, look at this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188 >>> >> >> Ouch. > > Indeed. > > changing the definition to: > struct ull { > unsigned long long v __attribute__((aligned(__alignof__(long long)))); > }; > > prints 8 for the structure alignment. So this will help force alignment of outer structures triggered by inner members, but only for globals and perhaps those on stack. I'm not sure how this helps aligning such a struct allocated dynamically - we are not passing this extra alignment info the the allocator API here. Surely the size will increase and we end up with extra padding in the end as intended originally and pointed to by Mark, but how does it help with alignment ? What am I missing ? > > Time to audit uses of __alignof__(). > > #define actual_alignof(type) __alignof__(struct { type jsdjdhjdjh; })