Re: [PATCH] mm: fix struct page layout on 32-bit systems

From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: stable <stable@vger.kernel.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Matteo Croce <mcroce@linux.microsoft.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: fix struct page layout on 32-bit systems
Date: Sun, 16 May 2021 09:29:41 -0700	[thread overview]
Message-ID: <CAHk-=wgTG0Bb30NzXX=3F=n-rHjVrQAHVzFFCxRKWTTu1QxABQ@mail.gmail.com> (raw)
In-Reply-To: <20210516121844.2860628-1-willy@infradead.org>

On Sun, May 16, 2021 at 5:19 AM Matthew Wilcox (Oracle)
<willy@infradead.org> wrote:
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers and
> need 64-bit DMA addresses (arm, mips, ppc) had their struct page
> inadvertently expanded in 2019.  When the dma_addr_t was added, it forced
> the alignment of the union to 8 bytes, which inserted a 4 byte gap between
> 'flags' and the union.

So I already have this in my tree, but this stable submission made me go "Hmm".

Why do we actually want a full 64-bit DMA address on 32-bit architectures here?

It strikes me that the address is page-aligned, and I suspect we could
just use a 32-bit "DMA page frame number" instead in 'struct page'?

So instead of that odd

+       if (sizeof(dma_addr_t) > sizeof(unsigned long))
+               ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;

maybe we could just do effectively

        ret + (dma_addr_t)page->dma_frame_nr << PAGE_SHIFT;

and simplify this all. We could do it on 64-bit too, just to not have
any opdd special cases (even if we'd have the full 64 bits available).

Hmm?

                Linus