From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by kanga.kvack.org (Postfix) with ESMTP id 7A2216B066A for ; Thu, 8 Nov 2018 16:31:30 -0500 (EST) Received: by mail-lj1-f199.google.com with SMTP id q185-v6so6429444ljb.14 for ; Thu, 08 Nov 2018 13:31:30 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id m10-v6sor3426590lje.8.2018.11.08.13.31.28 for (Google Transport Security); Thu, 08 Nov 2018 13:31:28 -0800 (PST) Date: Fri, 9 Nov 2018 00:31:26 +0300 From: Cyrill Gorcunov Subject: Re: [PATCH v5 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Message-ID: <20181108213126.GD13195@uranus.lan> References: <20181011151523.27101-1-yu-cheng.yu@intel.com> <20181011151523.27101-5-yu-cheng.yu@intel.com> <4295b8f786c10c469870a6d9725749ce75dcdaa2.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: Yu-cheng Yu , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H. J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , "Shanbhogue, Vedvyas" On Thu, Nov 08, 2018 at 01:22:54PM -0800, Andy Lutomirski wrote: > > > > > > Why are these __packed? It seems like it'll generate bad code for no > > > obvious purpose. > > > > That prevents any possibility that the compiler will insert padding, although in > > 64-bit kernel this should not happen to either struct. Also all xstate > > components here are packed. > > > > They both seem like bugs, perhaps. As I understand it, __packed > removes padding, but it also forces the compiler to expect the fields > to be unaligned even if they are actually aligned. How is that? Andy, mind to point where you get that this attribute forces compiler to make such assumption?