From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8E7DC433ED for ; Sat, 10 Apr 2021 19:11:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7F7CA61185 for ; Sat, 10 Apr 2021 19:11:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234957AbhDJTLV (ORCPT ); Sat, 10 Apr 2021 15:11:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:45068 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234768AbhDJTLS (ORCPT ); Sat, 10 Apr 2021 15:11:18 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BC6966113A; Sat, 10 Apr 2021 19:11:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618081863; bh=rBfw+r2um68UpFbzVkxVlHHyJ+hgFPf/zBrFYQw7TNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CIhhz328zzet5a/BvXZzSs9qZeOvsRmdTIQX8oHvPt4oPq31f6SdMiRQlV3wwxeNa GmirfKbnBbXy13rC5mPC5X4IYTxOrbfSp201pVc2ivwXNFWXhMjpUUd6Z3P6GdAypc hXQbk3jNgzXE4abVKr5LlTbMx3yus3tJYykOkPF4g5QUy/4sEmN3QnSl1XUTyImSG8 +nrIDp4z3hEGajjGuvQYOwmAvld9GZf6ZqRXKlZ6kJNOxc2eYZ8HIjAVZ3TijeONug 5j3gyVLCEPaB6nGAjThA9V1IH5nKdc2cpKmOF0OJJIEPxgrvw2FaG4CSqtEAVnEU7R BXNDi+Akq/Lhw== Received: by mail-ot1-f47.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so8973160otn.1; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) X-Gm-Message-State: AOAM531Gu7ZroMfzZPVK+zswSeVKSRAt6gNScNWY7toYwzv0pgTbqngs YoYRoVagkOv02V8N9BihJZYRoDdswmEDZttOAdg= X-Google-Smtp-Source: ABdhPJy5fKRN+b0N+vdm7HuaN0voD9Ksx0FbjR4NiXXEFlqO3Rbtb6TftW/JNl1MSl+hXOUABL/gf3HkAiDbD0wFK7g= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr17843523otq.251.1618081863076; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20210409185105.188284-3-willy@infradead.org> <202104100656.N7EVvkNZ-lkp@intel.com> <20210410024313.GX2531743@casper.infradead.org> In-Reply-To: <20210410024313.GX2531743@casper.infradead.org> From: Arnd Bergmann Date: Sat, 10 Apr 2021 21:10:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bogus struct page layout on 32-bit To: Matthew Wilcox Cc: kernel test robot , Linux-MM , kbuild-all@lists.01.org, clang-built-linux , Linux Kernel Mailing List , Linux FS-devel Mailing List , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Linux ARM , Jesper Dangaard Brouer , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrote: > + dma_addr_t dma_addr __packed; > }; > struct { /* slab, slob and slub */ > union { > > but I don't know if GCC is smart enough to realise that dma_addr is now > on an 8 byte boundary and it can use a normal instruction to access it, > or whether it'll do something daft like use byte loads to access it. > > We could also do: > > + dma_addr_t dma_addr __packed __aligned(sizeof(void *)); > > and I see pahole, at least sees this correctly: > > struct { > long unsigned int _page_pool_pad; /* 4 4 */ > dma_addr_t dma_addr __attribute__((__aligned__(4))); /* 8 8 */ > } __attribute__((__packed__)) __attribute__((__aligned__(4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3 struct page { short a; struct { short b; long long c __attribute__((packed, aligned(2))); } __attribute__((packed)); } __attribute__((aligned(8))); In this structure, 'c' is clearly aligned to eight bytes, and gcc does realize that it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on struct members with less than 4 byte alignment. However, it also complains that passing a pointer to 'c' into a function that expects a 'long long' is not allowed because alignof(c) is only '2' here. (I used 'short' here because I having a 64-bit member misaligned by four bytes wouldn't make a difference to the instructions on Arm, or any other 32-bit architecture I can think of, regardless of the ABI requirements). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41CD6C43460 for ; Sat, 10 Apr 2021 19:11:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8D576113A for ; Sat, 10 Apr 2021 19:11:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8D576113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 48ED98E0002; Sat, 10 Apr 2021 15:11:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 416518E0001; Sat, 10 Apr 2021 15:11:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28FF48E0002; Sat, 10 Apr 2021 15:11:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 0A6828E0001 for ; Sat, 10 Apr 2021 15:11:07 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BBD6240D7 for ; Sat, 10 Apr 2021 19:11:06 +0000 (UTC) X-FDA: 78017400132.38.6F7DE04 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP id 8FCDDE8 for ; Sat, 10 Apr 2021 19:11:04 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C8318611C1 for ; Sat, 10 Apr 2021 19:11:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618081863; bh=rBfw+r2um68UpFbzVkxVlHHyJ+hgFPf/zBrFYQw7TNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CIhhz328zzet5a/BvXZzSs9qZeOvsRmdTIQX8oHvPt4oPq31f6SdMiRQlV3wwxeNa GmirfKbnBbXy13rC5mPC5X4IYTxOrbfSp201pVc2ivwXNFWXhMjpUUd6Z3P6GdAypc hXQbk3jNgzXE4abVKr5LlTbMx3yus3tJYykOkPF4g5QUy/4sEmN3QnSl1XUTyImSG8 +nrIDp4z3hEGajjGuvQYOwmAvld9GZf6ZqRXKlZ6kJNOxc2eYZ8HIjAVZ3TijeONug 5j3gyVLCEPaB6nGAjThA9V1IH5nKdc2cpKmOF0OJJIEPxgrvw2FaG4CSqtEAVnEU7R BXNDi+Akq/Lhw== Received: by mail-ot1-f48.google.com with SMTP id t23-20020a0568301e37b02901b65ab30024so8965198otr.4 for ; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) X-Gm-Message-State: AOAM530Xv8Lh98+a5Cr4jXSCwgIlIdaggmF+LiARL65pnWNWbK1CM12W fHrNLIdnHeJmETkLS09vXZOva+iiYxCZkRiZBHg= X-Google-Smtp-Source: ABdhPJy5fKRN+b0N+vdm7HuaN0voD9Ksx0FbjR4NiXXEFlqO3Rbtb6TftW/JNl1MSl+hXOUABL/gf3HkAiDbD0wFK7g= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr17843523otq.251.1618081863076; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20210409185105.188284-3-willy@infradead.org> <202104100656.N7EVvkNZ-lkp@intel.com> <20210410024313.GX2531743@casper.infradead.org> In-Reply-To: <20210410024313.GX2531743@casper.infradead.org> From: Arnd Bergmann Date: Sat, 10 Apr 2021 21:10:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bogus struct page layout on 32-bit To: Matthew Wilcox Cc: kernel test robot , Linux-MM , kbuild-all@lists.01.org, clang-built-linux , Linux Kernel Mailing List , Linux FS-devel Mailing List , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Linux ARM , Jesper Dangaard Brouer , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8FCDDE8 X-Stat-Signature: qka8oh8t5yax7o7xxisjmk97n3jef38t Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618081864-789221 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrote: > + dma_addr_t dma_addr __packed; > }; > struct { /* slab, slob and slub */ > union { > > but I don't know if GCC is smart enough to realise that dma_addr is now > on an 8 byte boundary and it can use a normal instruction to access it, > or whether it'll do something daft like use byte loads to access it. > > We could also do: > > + dma_addr_t dma_addr __packed __aligned(sizeof(void *)); > > and I see pahole, at least sees this correctly: > > struct { > long unsigned int _page_pool_pad; /* 4 4 */ > dma_addr_t dma_addr __attribute__((__aligned__(4))); /* 8 8 */ > } __attribute__((__packed__)) __attribute__((__aligned__(4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3 struct page { short a; struct { short b; long long c __attribute__((packed, aligned(2))); } __attribute__((packed)); } __attribute__((aligned(8))); In this structure, 'c' is clearly aligned to eight bytes, and gcc does realize that it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on struct members with less than 4 byte alignment. However, it also complains that passing a pointer to 'c' into a function that expects a 'long long' is not allowed because alignof(c) is only '2' here. (I used 'short' here because I having a 64-bit member misaligned by four bytes wouldn't make a difference to the instructions on Arm, or any other 32-bit architecture I can think of, regardless of the ABI requirements). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4259CC433B4 for ; Sat, 10 Apr 2021 19:11:34 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 99F766113A for ; Sat, 10 Apr 2021 19:11:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99F766113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FHl3S1PTDz3bx3 for ; Sun, 11 Apr 2021 05:11:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=CIhhz328; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=arnd@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=CIhhz328; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FHl2z0KWvz2yyM for ; Sun, 11 Apr 2021 05:11:06 +1000 (AEST) Received: by mail.kernel.org (Postfix) with ESMTPSA id C2CC2611AF for ; Sat, 10 Apr 2021 19:11:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618081863; bh=rBfw+r2um68UpFbzVkxVlHHyJ+hgFPf/zBrFYQw7TNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CIhhz328zzet5a/BvXZzSs9qZeOvsRmdTIQX8oHvPt4oPq31f6SdMiRQlV3wwxeNa GmirfKbnBbXy13rC5mPC5X4IYTxOrbfSp201pVc2ivwXNFWXhMjpUUd6Z3P6GdAypc hXQbk3jNgzXE4abVKr5LlTbMx3yus3tJYykOkPF4g5QUy/4sEmN3QnSl1XUTyImSG8 +nrIDp4z3hEGajjGuvQYOwmAvld9GZf6ZqRXKlZ6kJNOxc2eYZ8HIjAVZ3TijeONug 5j3gyVLCEPaB6nGAjThA9V1IH5nKdc2cpKmOF0OJJIEPxgrvw2FaG4CSqtEAVnEU7R BXNDi+Akq/Lhw== Received: by mail-ot1-f42.google.com with SMTP id v24-20020a9d69d80000b02901b9aec33371so8983428oto.2 for ; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) X-Gm-Message-State: AOAM532clOMaMOkCMiTGX/GSrajPzMXgcRrpgPartsdG4px+fHiVkHUt kMNJEpjvfztvSZJ8xQ09qX3BFF/iVjoUscrvjlk= X-Google-Smtp-Source: ABdhPJy5fKRN+b0N+vdm7HuaN0voD9Ksx0FbjR4NiXXEFlqO3Rbtb6TftW/JNl1MSl+hXOUABL/gf3HkAiDbD0wFK7g= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr17843523otq.251.1618081863076; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20210409185105.188284-3-willy@infradead.org> <202104100656.N7EVvkNZ-lkp@intel.com> <20210410024313.GX2531743@casper.infradead.org> In-Reply-To: <20210410024313.GX2531743@casper.infradead.org> From: Arnd Bergmann Date: Sat, 10 Apr 2021 21:10:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bogus struct page layout on 32-bit To: Matthew Wilcox Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kbuild-all@lists.01.org, kernel test robot , clang-built-linux , Jesper Dangaard Brouer , Linux Kernel Mailing List , Linux-MM , Paul Mackerras , Linux FS-devel Mailing List , linuxppc-dev , "David S. Miller" , Linux ARM Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrote: > + dma_addr_t dma_addr __packed; > }; > struct { /* slab, slob and slub */ > union { > > but I don't know if GCC is smart enough to realise that dma_addr is now > on an 8 byte boundary and it can use a normal instruction to access it, > or whether it'll do something daft like use byte loads to access it. > > We could also do: > > + dma_addr_t dma_addr __packed __aligned(sizeof(void *)); > > and I see pahole, at least sees this correctly: > > struct { > long unsigned int _page_pool_pad; /* 4 4 */ > dma_addr_t dma_addr __attribute__((__aligned__(4))); /* 8 8 */ > } __attribute__((__packed__)) __attribute__((__aligned__(4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3 struct page { short a; struct { short b; long long c __attribute__((packed, aligned(2))); } __attribute__((packed)); } __attribute__((aligned(8))); In this structure, 'c' is clearly aligned to eight bytes, and gcc does realize that it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on struct members with less than 4 byte alignment. However, it also complains that passing a pointer to 'c' into a function that expects a 'long long' is not allowed because alignof(c) is only '2' here. (I used 'short' here because I having a 64-bit member misaligned by four bytes wouldn't make a difference to the instructions on Arm, or any other 32-bit architecture I can think of, regardless of the ABI requirements). Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FF1DC433B4 for ; Sat, 10 Apr 2021 19:12:49 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A7C1C6113A for ; Sat, 10 Apr 2021 19:12:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7C1C6113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bSKmyBOTrLNt0lQD6ToCa1meg/o9/S6vv1QsyYjaivo=; b=pdg/OuExxeIy4OezTogaHs/8/ k+5z7wBcg3TLLbJt4oG1koS+WkAfBOLiAfVi4CEhnA6UCvju5OITNIisINhJcWGnbLOdvVcTBcNKK xKr8P01T9fzXHEwXLBI+PD2t7yQmvvjHXEzoadhN0ZPdAjvdAV9YL3ZsKEy/4gLyT1b0/v/3eDlG8 wHJKYRomUflh6Ap1dXQSpkNFTjZdyZvFH7k6E9tItgdWFA+RMeH0QvrbFQK6kYTpwwftLsmCF1Owz dtYONhTm1KoY1WY55KqPgY5vmQnHAEUGOpsNysZauC2u2iH3Uia6xRENRM1kYZqmAAW/4sQMBU4uM I7+SS8bvw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lVJ0k-003JBt-3u; Sat, 10 Apr 2021 19:11:14 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lVJ0d-003JBd-Ic for linux-arm-kernel@desiato.infradead.org; Sat, 10 Apr 2021 19:11:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fqNinNAhhPaTU2cij2p+HaHNg/J69IJOBSNDmdxs+TY=; b=W0sQ3Z+1QrPefwKDXHuyVUsOvl FgJYFCVwDzoWjcyTpgeTAPqaDhpKJpPaHMh6mJS9aywMAood8Fi1aoThBzAhjY7JUBSO6J4m4HxgH xWkgno9xY9mKeGvunF1qRXhb2YoXEdpy3HVb4BsDbNS3n3jo3+MxA4p1Qyv5Ogc8TterbePc5oqkU Oa7HJnsDEb1QliAIBY7k7F0MlG97m9yStIXz1/jyaDd6ifQxrRogmTqc1vaND4HcWJEU+VCNddPIS eVwz6gKjpZCfmPYY9VKvlpIPcHhjDwE+Av5mhpKvGUlkgN+bzC61AuqtVz0D91DVo7f8LBciedI2e /FxwrFYQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lVJ0a-005E8e-UC for linux-arm-kernel@lists.infradead.org; Sat, 10 Apr 2021 19:11:06 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CCAB0611C9 for ; Sat, 10 Apr 2021 19:11:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618081863; bh=rBfw+r2um68UpFbzVkxVlHHyJ+hgFPf/zBrFYQw7TNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CIhhz328zzet5a/BvXZzSs9qZeOvsRmdTIQX8oHvPt4oPq31f6SdMiRQlV3wwxeNa GmirfKbnBbXy13rC5mPC5X4IYTxOrbfSp201pVc2ivwXNFWXhMjpUUd6Z3P6GdAypc hXQbk3jNgzXE4abVKr5LlTbMx3yus3tJYykOkPF4g5QUy/4sEmN3QnSl1XUTyImSG8 +nrIDp4z3hEGajjGuvQYOwmAvld9GZf6ZqRXKlZ6kJNOxc2eYZ8HIjAVZ3TijeONug 5j3gyVLCEPaB6nGAjThA9V1IH5nKdc2cpKmOF0OJJIEPxgrvw2FaG4CSqtEAVnEU7R BXNDi+Akq/Lhw== Received: by mail-ot1-f49.google.com with SMTP id d3-20020a9d29030000b029027e8019067fso7033574otb.13 for ; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) X-Gm-Message-State: AOAM532H95C+hsBqfrrauz2QjPCKk4mvLbIhzGIvUap3v3pghzPlDTr/ TKdZgLAzZUDpjEFLjSQBCZ52mnX8BKMrd9a+8fs= X-Google-Smtp-Source: ABdhPJy5fKRN+b0N+vdm7HuaN0voD9Ksx0FbjR4NiXXEFlqO3Rbtb6TftW/JNl1MSl+hXOUABL/gf3HkAiDbD0wFK7g= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr17843523otq.251.1618081863076; Sat, 10 Apr 2021 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20210409185105.188284-3-willy@infradead.org> <202104100656.N7EVvkNZ-lkp@intel.com> <20210410024313.GX2531743@casper.infradead.org> In-Reply-To: <20210410024313.GX2531743@casper.infradead.org> From: Arnd Bergmann Date: Sat, 10 Apr 2021 21:10:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bogus struct page layout on 32-bit To: Matthew Wilcox Cc: kernel test robot , Linux-MM , kbuild-all@lists.01.org, clang-built-linux , Linux Kernel Mailing List , Linux FS-devel Mailing List , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , Linux ARM , Jesper Dangaard Brouer , "David S. Miller" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210410_121105_052781_C40F1441 X-CRM114-Status: GOOD ( 18.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrote: > + dma_addr_t dma_addr __packed; > }; > struct { /* slab, slob and slub */ > union { > > but I don't know if GCC is smart enough to realise that dma_addr is now > on an 8 byte boundary and it can use a normal instruction to access it, > or whether it'll do something daft like use byte loads to access it. > > We could also do: > > + dma_addr_t dma_addr __packed __aligned(sizeof(void *)); > > and I see pahole, at least sees this correctly: > > struct { > long unsigned int _page_pool_pad; /* 4 4 */ > dma_addr_t dma_addr __attribute__((__aligned__(4))); /* 8 8 */ > } __attribute__((__packed__)) __attribute__((__aligned__(4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3 struct page { short a; struct { short b; long long c __attribute__((packed, aligned(2))); } __attribute__((packed)); } __attribute__((aligned(8))); In this structure, 'c' is clearly aligned to eight bytes, and gcc does realize that it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on struct members with less than 4 byte alignment. However, it also complains that passing a pointer to 'c' into a function that expects a 'long long' is not allowed because alignof(c) is only '2' here. (I used 'short' here because I having a 64-bit member misaligned by four bytes wouldn't make a difference to the instructions on Arm, or any other 32-bit architecture I can think of, regardless of the ABI requirements). Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5339446849900647875==" MIME-Version: 1.0 From: Arnd Bergmann To: kbuild-all@lists.01.org Subject: Re: Bogus struct page layout on 32-bit Date: Sat, 10 Apr 2021 21:10:47 +0200 Message-ID: In-Reply-To: <20210410024313.GX2531743@casper.infradead.org> List-Id: --===============5339446849900647875== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox wrot= e: > + dma_addr_t dma_addr __packed; > }; > struct { /* slab, slob and slub */ > union { > > but I don't know if GCC is smart enough to realise that dma_addr is now > on an 8 byte boundary and it can use a normal instruction to access it, > or whether it'll do something daft like use byte loads to access it. > > We could also do: > > + dma_addr_t dma_addr __packed __aligned(sizeof(voi= d *)); > > and I see pahole, at least sees this correctly: > > struct { > long unsigned int _page_pool_pad; /* 4 4 = */ > dma_addr_t dma_addr __attribute__((__aligned__(4)= )); /* 8 8 */ > } __attribute__((__packed__)) __attribute__((__aligned__(= 4))); > > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t > / dma_addr_t. Advice, please? I've tried out what gcc would make of this: https://godbolt.org/z/aTEbxxbG3 struct page { short a; struct { short b; long long c __attribute__((packed, aligned(2))); } __attribute__((packed)); } __attribute__((aligned(8))); In this structure, 'c' is clearly aligned to eight bytes, and gcc does realize that it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden= on struct members with less than 4 byte alignment. However, it also complains that passing a pointer to 'c' into a function that expects a 'long long' is= not allowed because alignof(c) is only '2' here. (I used 'short' here because I having a 64-bit member misaligned by four bytes wouldn't make a difference to the instructions on Arm, or any other 32-bit architecture I can think of, regardless of the ABI requirements). Arnd --===============5339446849900647875==--