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, HEADER_FROM_DIFFERENT_DOMAINS,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 058FCC433ED for ; Wed, 14 Apr 2021 21:56:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D6C0961074 for ; Wed, 14 Apr 2021 21:56:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229882AbhDNV5J convert rfc822-to-8bit (ORCPT ); Wed, 14 Apr 2021 17:57:09 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:34617 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229493AbhDNV5F (ORCPT ); Wed, 14 Apr 2021 17:57:05 -0400 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mtapsc-4-PsdLgvNoPOivxmwyvxbtWw-1; Wed, 14 Apr 2021 22:56:40 +0100 X-MC-Unique: PsdLgvNoPOivxmwyvxbtWw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 22:56:39 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.012; Wed, 14 Apr 2021 22:56:39 +0100 From: David Laight To: 'Matthew Wilcox' , Jesper Dangaard Brouer CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , Ilias Apalodimas , Matteo Croce , Grygorii Strashko , Arnd Bergmann , "Christoph Hellwig" Subject: RE: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Topic: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Index: AQHXMXYmwdfrgigLI0exh4xFUSZq9Kq0jZ3g Date: Wed, 14 Apr 2021 21:56:39 +0000 Message-ID: References: <20210410205246.507048-1-willy@infradead.org> <20210410205246.507048-2-willy@infradead.org> <20210411114307.5087f958@carbon> <20210411103318.GC2531743@casper.infradead.org> <20210412011532.GG2531743@casper.infradead.org> <20210414101044.19da09df@carbon> <20210414115052.GS2531743@casper.infradead.org> <20210414211322.3799afd4@carbon> <20210414213556.GY2531743@casper.infradead.org> In-Reply-To: <20210414213556.GY2531743@casper.infradead.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Matthew Wilcox > Sent: 14 April 2021 22:36 > > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote: > > (If others want to reproduce). First I could not reproduce on ARM32. > > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to > > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT. > > hmmm ... you should be able to provoke it by enabling ARM_LPAE, > which selects PHYS_ADDR_T_64BIT, and > > config ARCH_DMA_ADDR_T_64BIT > def_bool 64BIT || PHYS_ADDR_T_64BIT > > > struct page { > > long unsigned int flags; /* 0 4 */ > > > > /* XXX 4 bytes hole, try to pack */ > > > > union { > > struct { > > struct list_head lru; /* 8 8 */ > > struct address_space * mapping; /* 16 4 */ > > long unsigned int index; /* 20 4 */ > > long unsigned int private; /* 24 4 */ > > }; /* 8 20 */ > > struct { > > dma_addr_t dma_addr Adding __packed here will remove the 4 byte hole before the union and the compiler seems clever enough to know that anything following a 'long' must also be 'long' aligned. So you don't get anything horrid like byte accesses. On 64bit dma_addr will remain 64bit aligned. On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access won't make any difference. So definitely the only simple fix. David > > ; /* 8 8 */ > > }; /* 8 8 */ > [...] > > } __attribute__((__aligned__(8))); /* 8 24 */ > > union { > > atomic_t _mapcount; /* 32 4 */ > > unsigned int page_type; /* 32 4 */ > > unsigned int active; /* 32 4 */ > > int units; /* 32 4 */ > > }; /* 32 4 */ > > atomic_t _refcount; /* 36 4 */ > > > > /* size: 40, cachelines: 1, members: 4 */ > > /* sum members: 36, holes: 1, sum holes: 4 */ > > /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */ > > /* last cacheline: 40 bytes */ > > } __attribute__((__aligned__(8))); > > If you also enable CONFIG_MEMCG or enough options to make > LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte > hole at the end. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) 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=-2.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,PDS_BAD_THREAD_QP_64, 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 8AAD6C433ED for ; Wed, 14 Apr 2021 21:56:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F68F6105A for ; Wed, 14 Apr 2021 21:56:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F68F6105A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7F94B6B006C; Wed, 14 Apr 2021 17:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 780456B0070; Wed, 14 Apr 2021 17:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D3626B0072; Wed, 14 Apr 2021 17:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 3EEB36B006C for ; Wed, 14 Apr 2021 17:56:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id EB23318327CC0 for ; Wed, 14 Apr 2021 21:56:43 +0000 (UTC) X-FDA: 78032332686.11.51E4146 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [207.82.80.151]) by imf01.hostedemail.com (Postfix) with ESMTP id 556545001528 for ; Wed, 14 Apr 2021 21:56:42 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mtapsc-4-PsdLgvNoPOivxmwyvxbtWw-1; Wed, 14 Apr 2021 22:56:40 +0100 X-MC-Unique: PsdLgvNoPOivxmwyvxbtWw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 22:56:39 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.012; Wed, 14 Apr 2021 22:56:39 +0100 From: David Laight To: 'Matthew Wilcox' , Jesper Dangaard Brouer CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , Ilias Apalodimas , Matteo Croce , Grygorii Strashko , Arnd Bergmann , "Christoph Hellwig" Subject: RE: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Topic: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Index: AQHXMXYmwdfrgigLI0exh4xFUSZq9Kq0jZ3g Date: Wed, 14 Apr 2021 21:56:39 +0000 Message-ID: References: <20210410205246.507048-1-willy@infradead.org> <20210410205246.507048-2-willy@infradead.org> <20210411114307.5087f958@carbon> <20210411103318.GC2531743@casper.infradead.org> <20210412011532.GG2531743@casper.infradead.org> <20210414101044.19da09df@carbon> <20210414115052.GS2531743@casper.infradead.org> <20210414211322.3799afd4@carbon> <20210414213556.GY2531743@casper.infradead.org> In-Reply-To: <20210414213556.GY2531743@casper.infradead.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 556545001528 X-Stat-Signature: ey9kre73crfaic4uk6zfi6p6uxthtibq X-Rspamd-Server: rspam02 Received-SPF: none (aculab.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=eu-smtp-delivery-151.mimecast.com; client-ip=207.82.80.151 X-HE-DKIM-Result: none/none X-HE-Tag: 1618437402-327528 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: From: Matthew Wilcox > Sent: 14 April 2021 22:36 >=20 > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote: > > (If others want to reproduce). First I could not reproduce on ARM32. > > Then I found out that enabling CONFIG_XEN on ARCH=3Darm was needed to > > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT. >=20 > hmmm ... you should be able to provoke it by enabling ARM_LPAE, > which selects PHYS_ADDR_T_64BIT, and >=20 > config ARCH_DMA_ADDR_T_64BIT > def_bool 64BIT || PHYS_ADDR_T_64BIT >=20 > > struct page { > > long unsigned int flags; /* 0 4= */ > > > > /* XXX 4 bytes hole, try to pack */ > > > > union { > > struct { > > struct list_head lru; /* 8 8= */ > > struct address_space * mapping; /* 16 4= */ > > long unsigned int index; /* 20 4= */ > > long unsigned int private; /* 24 4= */ > > }; /* 8 20= */ > > struct { > > dma_addr_t dma_addr Adding __packed here will remove the 4 byte hole before the union and the compiler seems clever enough to know that anything following a 'long' must also be 'long' aligned. So you don't get anything horrid like byte accesses. On 64bit dma_addr will remain 64bit aligned. On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access won't make any difference. So definitely the only simple fix. =09David > > ; /* 8 8= */ > > }; /* 8 8= */ > [...] > > } __attribute__((__aligned__(8))); /* 8 24= */ > > union { > > atomic_t _mapcount; /* 32 4= */ > > unsigned int page_type; /* 32 4= */ > > unsigned int active; /* 32 4= */ > > int units; /* 32 4= */ > > }; /* 32 4= */ > > atomic_t _refcount; /* 36 4= */ > > > > /* size: 40, cachelines: 1, members: 4 */ > > /* sum members: 36, holes: 1, sum holes: 4 */ > > /* forced alignments: 1, forced holes: 1, sum forced holes: 4 *= / > > /* last cacheline: 40 bytes */ > > } __attribute__((__aligned__(8))); >=20 > If you also enable CONFIG_MEMCG or enough options to make > LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte > hole at the end. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) 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=-2.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,PDS_BAD_THREAD_QP_64, 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 356A7C433B4 for ; Wed, 14 Apr 2021 21:58:27 +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 87B9F61179 for ; Wed, 14 Apr 2021 21:58:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 87B9F61179 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM 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 4FLGZ90S00z3c0k for ; Thu, 15 Apr 2021 07:58:25 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.85.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (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 4FLGYm2k9Bz2xZM for ; Thu, 15 Apr 2021 07:58:04 +1000 (AEST) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mtapsc-4-PsdLgvNoPOivxmwyvxbtWw-1; Wed, 14 Apr 2021 22:56:40 +0100 X-MC-Unique: PsdLgvNoPOivxmwyvxbtWw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 22:56:39 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.012; Wed, 14 Apr 2021 22:56:39 +0100 From: David Laight To: 'Matthew Wilcox' , Jesper Dangaard Brouer Subject: RE: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Topic: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Index: AQHXMXYmwdfrgigLI0exh4xFUSZq9Kq0jZ3g Date: Wed, 14 Apr 2021 21:56:39 +0000 Message-ID: References: <20210410205246.507048-1-willy@infradead.org> <20210410205246.507048-2-willy@infradead.org> <20210411114307.5087f958@carbon> <20210411103318.GC2531743@casper.infradead.org> <20210412011532.GG2531743@casper.infradead.org> <20210414101044.19da09df@carbon> <20210414115052.GS2531743@casper.infradead.org> <20210414211322.3799afd4@carbon> <20210414213556.GY2531743@casper.infradead.org> In-Reply-To: <20210414213556.GY2531743@casper.infradead.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Arnd Bergmann , Grygorii Strashko , "netdev@vger.kernel.org" , Ilias Apalodimas , "linux-mips@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Matteo Croce , "linuxppc-dev@lists.ozlabs.org" , Christoph Hellwig , "linux-arm-kernel@lists.infradead.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Matthew Wilcox > Sent: 14 April 2021 22:36 >=20 > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote: > > (If others want to reproduce). First I could not reproduce on ARM32. > > Then I found out that enabling CONFIG_XEN on ARCH=3Darm was needed to > > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT. >=20 > hmmm ... you should be able to provoke it by enabling ARM_LPAE, > which selects PHYS_ADDR_T_64BIT, and >=20 > config ARCH_DMA_ADDR_T_64BIT > def_bool 64BIT || PHYS_ADDR_T_64BIT >=20 > > struct page { > > long unsigned int flags; /* 0 4= */ > > > > /* XXX 4 bytes hole, try to pack */ > > > > union { > > struct { > > struct list_head lru; /* 8 8= */ > > struct address_space * mapping; /* 16 4= */ > > long unsigned int index; /* 20 4= */ > > long unsigned int private; /* 24 4= */ > > }; /* 8 20= */ > > struct { > > dma_addr_t dma_addr Adding __packed here will remove the 4 byte hole before the union and the compiler seems clever enough to know that anything following a 'long' must also be 'long' aligned. So you don't get anything horrid like byte accesses. On 64bit dma_addr will remain 64bit aligned. On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access won't make any difference. So definitely the only simple fix. =09David > > ; /* 8 8= */ > > }; /* 8 8= */ > [...] > > } __attribute__((__aligned__(8))); /* 8 24= */ > > union { > > atomic_t _mapcount; /* 32 4= */ > > unsigned int page_type; /* 32 4= */ > > unsigned int active; /* 32 4= */ > > int units; /* 32 4= */ > > }; /* 32 4= */ > > atomic_t _refcount; /* 36 4= */ > > > > /* size: 40, cachelines: 1, members: 4 */ > > /* sum members: 36, holes: 1, sum holes: 4 */ > > /* forced alignments: 1, forced holes: 1, sum forced holes: 4 *= / > > /* last cacheline: 40 bytes */ > > } __attribute__((__aligned__(8))); >=20 > If you also enable CONFIG_MEMCG or enough options to make > LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte > hole at the end. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 758ABC433B4 for ; Wed, 14 Apr 2021 21:59:11 +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 DBB0B61177 for ; Wed, 14 Apr 2021 21:59:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBB0B61177 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM 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:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:CC:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SonQUtuWr8XLOdWIPe/b4p43TXvj4Qp5t5QUnPI3sYE=; b=Y/BOCMw6/5uvzXNX8Uu1ql5H0 DfqYpnnSVtxwdJNK+6J3Bdc5r7q3qBuT0GAiIQDATVmvRPmSPVWEDN9tzIOpDv6dQdxKjdRSFVB3V rwki9ECLE810bufvuL5dZPhSXOxgRRa/XusnHdiodFE9punoahdHrnNrIHLRyIhQpILf4ZKcvDd9T sVADKcshVuErAlCGnsUuSOGuBgNz0FkeyxlKPWMS9BdrPKtjYOPHhQ59t7koQj5OLlM2nYT9cvBix iek61F6Ub5DQbegu0mjXJMHwBw2RmRC8KT+kzHJ8At1AAtsmctYX3/4J2zRvB6rJm7r+xbrpcR+iM jq/qg5dUQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lWnVG-00Dwar-Tc; Wed, 14 Apr 2021 21:56:55 +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 1lWnVA-00DwZy-PV for linux-arm-kernel@desiato.infradead.org; Wed, 14 Apr 2021 21:56:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:MIME-Version:In-Reply-To:References:Message-ID:Date:Subject:CC: To:From:Sender:Reply-To:Content-ID:Content-Description; bh=0cuBVqvUUSV2XvCgddoNzhmwpeCY1aOa2n11G1zp3K0=; b=jBpb/7qtWKMPQNZ82CWMtQAAkb jCbXTQBRhx/X1IrVP+V+yNWjDBwVdPAa6iQ4X7seBqD30rzAXDxJIe/9qmlON7OXSp1uePMxV9P/Z yTSbvUNzQgS9FzpKzeuTMKi2RANREBFi//Obq3yw2EO1grtNH+JXACZ1rR2PnFXi/OB8okXFPNSAU PZVwrOGIpQAh6EFO6Ogh10wr5qGm8Bf+8sc4UYM6K2efXgLr1Se+ws5lEetd/RvBfcydspP6Fy6NT tUglsGsvnXmtmBQEhpsf3QjQTCyeb8bV8uv8OUw59Xp6i199JhAy1h4TyZBcgagsLc2mlKKa2x9FQ 376tgTMA==; Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lWnV6-00889N-EU for linux-arm-kernel@lists.infradead.org; Wed, 14 Apr 2021 21:56:47 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mtapsc-4-PsdLgvNoPOivxmwyvxbtWw-1; Wed, 14 Apr 2021 22:56:40 +0100 X-MC-Unique: PsdLgvNoPOivxmwyvxbtWw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 22:56:39 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.012; Wed, 14 Apr 2021 22:56:39 +0100 From: David Laight To: 'Matthew Wilcox' , Jesper Dangaard Brouer CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mips@vger.kernel.org" , Ilias Apalodimas , Matteo Croce , Grygorii Strashko , Arnd Bergmann , "Christoph Hellwig" Subject: RE: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Topic: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems Thread-Index: AQHXMXYmwdfrgigLI0exh4xFUSZq9Kq0jZ3g Date: Wed, 14 Apr 2021 21:56:39 +0000 Message-ID: References: <20210410205246.507048-1-willy@infradead.org> <20210410205246.507048-2-willy@infradead.org> <20210411114307.5087f958@carbon> <20210411103318.GC2531743@casper.infradead.org> <20210412011532.GG2531743@casper.infradead.org> <20210414101044.19da09df@carbon> <20210414115052.GS2531743@casper.infradead.org> <20210414211322.3799afd4@carbon> <20210414213556.GY2531743@casper.infradead.org> In-Reply-To: <20210414213556.GY2531743@casper.infradead.org> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210414_145644_791155_99A13B7E X-CRM114-Status: GOOD ( 18.07 ) 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 From: Matthew Wilcox > Sent: 14 April 2021 22:36 > > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote: > > (If others want to reproduce). First I could not reproduce on ARM32. > > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to > > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT. > > hmmm ... you should be able to provoke it by enabling ARM_LPAE, > which selects PHYS_ADDR_T_64BIT, and > > config ARCH_DMA_ADDR_T_64BIT > def_bool 64BIT || PHYS_ADDR_T_64BIT > > > struct page { > > long unsigned int flags; /* 0 4 */ > > > > /* XXX 4 bytes hole, try to pack */ > > > > union { > > struct { > > struct list_head lru; /* 8 8 */ > > struct address_space * mapping; /* 16 4 */ > > long unsigned int index; /* 20 4 */ > > long unsigned int private; /* 24 4 */ > > }; /* 8 20 */ > > struct { > > dma_addr_t dma_addr Adding __packed here will remove the 4 byte hole before the union and the compiler seems clever enough to know that anything following a 'long' must also be 'long' aligned. So you don't get anything horrid like byte accesses. On 64bit dma_addr will remain 64bit aligned. On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access won't make any difference. So definitely the only simple fix. David > > ; /* 8 8 */ > > }; /* 8 8 */ > [...] > > } __attribute__((__aligned__(8))); /* 8 24 */ > > union { > > atomic_t _mapcount; /* 32 4 */ > > unsigned int page_type; /* 32 4 */ > > unsigned int active; /* 32 4 */ > > int units; /* 32 4 */ > > }; /* 32 4 */ > > atomic_t _refcount; /* 36 4 */ > > > > /* size: 40, cachelines: 1, members: 4 */ > > /* sum members: 36, holes: 1, sum holes: 4 */ > > /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */ > > /* last cacheline: 40 bytes */ > > } __attribute__((__aligned__(8))); > > If you also enable CONFIG_MEMCG or enough options to make > LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte > hole at the end. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel