Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp45117imu; Thu, 8 Nov 2018 14:29:01 -0800 (PST) X-Google-Smtp-Source: AJdET5fZnW08cXLWB/axwXsitbW8R5STVuL1XyFByMEtS8KQJYYQjFlcveuEN0HWIkzVRzezGN6I X-Received: by 2002:a17:902:b612:: with SMTP id b18-v6mr6484826pls.205.1541716141676; Thu, 08 Nov 2018 14:29:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541716141; cv=none; d=google.com; s=arc-20160816; b=TwmdsugUWACzJWckFt+O0jYbcIhNbRqi4XXhpXI/mXe80m6rJesI5kEFmS5SVFA8gE kQ/R2EhhMkyrokyNjFN/pnUHUKB/fBKkiwWxW/om9+Rc4ZjlUx4HZGdR+amh/GPAy32C ++jABNFD68hsdqJoVtlIHNUkJ7vvnBVZDkhhJoGBRLCmyX6ZT3RfD1Q/KUHf18EEYsQK TzGtYH7Xhug1e6dLS6oke52d5CiF/UjK1cKKnwlpmfN6q/e3SnERvOQGJ63zA988rWpT 5FmVUCg3yeuJyVsKD8eSagQAJ83nTr3bJG0ubt4ShGpVYPZc2ATLogWxKvu/kiY9ez0L dTzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=c0rxaB2PIdvh0q4KbBuieb1EMfBo7ObRax+JeMJGg6g=; b=UMO0SHEjg/QYCjZ2qm50CXcRM+TpralvUzahSzhgmkup98dmAn12Amlu5CJArbrTb1 d/erMQdOd/ONCqml8z+9n1p0UxxPDC8DLhPTFU2H5fcOUhy55n+4Fems24EtWjHQa1cB j1g7E1X3CXNqjEKzgVDUB09Ev4o3ZlqKJLigrG5nzrGiowb2tqBwfEFAlxryvAxw6gtl y4/F1+epUY0t1lAnG7OGctosJULXWBi2kwipev3MHhh1uOYj1tYLmUDQTzlJvtOOi/Ea 9gBTyvDennQTX4Lg0M+skgHrgqkSuppMpbYWNU0FleM764GWcSKB+d0UMTr5ruKlG9jL w6jQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="Xid/XfkV"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n13si555823pgp.307.2018.11.08.14.28.45; Thu, 08 Nov 2018 14:29:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b="Xid/XfkV"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730946AbeKIHj1 (ORCPT + 99 others); Fri, 9 Nov 2018 02:39:27 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:34077 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729686AbeKIHj1 (ORCPT ); Fri, 9 Nov 2018 02:39:27 -0500 Received: by mail-wr1-f68.google.com with SMTP id j26-v6so22898680wre.1 for ; Thu, 08 Nov 2018 14:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c0rxaB2PIdvh0q4KbBuieb1EMfBo7ObRax+JeMJGg6g=; b=Xid/XfkVp97YJrsA6M/ulFTvpP8FftVWQjxjTBdVsUc3JWbwRjyU2J/x39XeB9TmOL k3B5+f5Lxz6SsQZ3urW/KNMBSCuEGJ6IBdlAihxRfC6DXbMYGvSWeR09Z8hlDoT0Es/h m0EHXF3YvQ3ORqu9ITatIyTaKcuyI76qQ8o5xgAihVlFW/+EWWhTVBm7A+Ifm7X4W9/5 kkGZw9w+/U8H33g7i/LLVfOoa2V5EuuveM7pM9UdQB95afOz8AMVtefpbJ7qFsM2JA+n nPK/4eci0DLiDDFnNzXj6XOCEcwKO+A4/f3UrBBUdnvlbyQttzRt9POb44r9sJtjUX+i RofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c0rxaB2PIdvh0q4KbBuieb1EMfBo7ObRax+JeMJGg6g=; b=rlqmKDDJuH9eaJrkQDMzm0v75eZtPpI0euO9X/tx+msXXZ61Ji7OCW27NxGLXQkFJV 0yigEeUiyeaSzD8BbMPunpVn//NXJd/+byI9mzYLkN7kwMKU/BRkWhzE/keoWTGRZAQz jFqXNjWuWEbmnE4PSS8VOeBwaaOXxyDgeUEAfhN5B800/E9tDwESTPKn+4enPrg/s1Nj 6R7ZHZuyjWdV4ku8gFLX7WqRCY4uRW/tVkA0qPmvdx+85JEmPlJASSHncw+wGdvLxufC rTaXTO45bA5vkcleGb8xLI0fHckXGAaxrEgD0UoO3dRVGTacdXaH4/r3A3acnp9GVMmd SXTw== X-Gm-Message-State: AGRZ1gKNbwEifnc3F3cwpBj4ebmXmUuS0BFiO7BPqOYNfyMB6Wbw0WQj +CeOgb42Y0MDNT8VUA8Lsou3jJmXGlivBmq2GUV5vg== X-Received: by 2002:adf:82c9:: with SMTP id 67-v6mr5368280wrc.131.1541714515017; Thu, 08 Nov 2018 14:01:55 -0800 (PST) MIME-Version: 1.0 References: <20181011151523.27101-1-yu-cheng.yu@intel.com> <20181011151523.27101-5-yu-cheng.yu@intel.com> <4295b8f786c10c469870a6d9725749ce75dcdaa2.camel@intel.com> <20181108213126.GD13195@uranus.lan> In-Reply-To: <20181108213126.GD13195@uranus.lan> From: Andy Lutomirski Date: Thu, 8 Nov 2018 14:01:42 -0800 Message-ID: Subject: Re: [PATCH v5 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack To: Cyrill Gorcunov 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 8, 2018 at 1:31 PM Cyrill Gorcunov wrote: > > 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? It's from memory. But gcc seems to agree with me I compiled this: struct foo { int x; } __attribute__((packed)); int read_foo(struct foo *f) { return f->x; } int align_of_foo_x(struct foo *f) { return __alignof__(f->x); } Compiling with -O2 gives: .globl read_foo .type read_foo, @function read_foo: movl (%rdi), %eax ret .size read_foo, .-read_foo .p2align 4,,15 .globl align_of_foo_x .type align_of_foo_x, @function align_of_foo_x: movl $1, %eax ret .size align_of_foo_x, .-align_of_foo_x So gcc thinks that the x field is one-byte-aligned, but the code is okay (at least in this instance) on x86. Building for armv5 gives: .type read_foo, %function read_foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldrb r3, [r0] @ zero_extendqisi2 ldrb r1, [r0, #1] @ zero_extendqisi2 ldrb r2, [r0, #2] @ zero_extendqisi2 orr r3, r3, r1, lsl #8 ldrb r0, [r0, #3] @ zero_extendqisi2 orr r3, r3, r2, lsl #16 orr r0, r3, r0, lsl #24 bx lr .size read_foo, .-read_foo .align 2 .global align_of_foo_x .syntax unified .arm .fpu vfpv3-d16 .type align_of_foo_x, %function So I'm pretty sure I'm right.