netdev - Re: [PATCH RFC 21/35] mm/cma: refuse handing out non-contiguous page ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aK2wlGYvCaFQXzBm@raptor>
Date: Tue, 26 Aug 2025 14:03:16 +0100
From: Alexandru Elisei <alexandru.elisei@....com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, Alexander Potapenko <glider@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Brendan Jackman <jackmanb@...gle.com>,
	Christoph Lameter <cl@...two.org>, Dennis Zhou <dennis@...nel.org>,
	Dmitry Vyukov <dvyukov@...gle.com>, dri-devel@...ts.freedesktop.org,
	intel-gfx@...ts.freedesktop.org, iommu@...ts.linux.dev,
	io-uring@...r.kernel.org, Jason Gunthorpe <jgg@...dia.com>,
	Jens Axboe <axboe@...nel.dk>, Johannes Weiner <hannes@...xchg.org>,
	John Hubbard <jhubbard@...dia.com>, kasan-dev@...glegroups.com,
	kvm@...r.kernel.org, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arm-kernel@...s.com, linux-arm-kernel@...ts.infradead.org,
	linux-crypto@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-mips@...r.kernel.org,
	linux-mmc@...r.kernel.org, linux-mm@...ck.org,
	linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
	linux-scsi@...r.kernel.org,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Marco Elver <elver@...gle.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Hocko <mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
	Muchun Song <muchun.song@...ux.dev>, netdev@...r.kernel.org,
	Oscar Salvador <osalvador@...e.de>, Peter Xu <peterx@...hat.com>,
	Robin Murphy <robin.murphy@....com>,
	Suren Baghdasaryan <surenb@...gle.com>, Tejun Heo <tj@...nel.org>,
	virtualization@...ts.linux.dev, Vlastimil Babka <vbabka@...e.cz>,
	wireguard@...ts.zx2c4.com, x86@...nel.org, Zi Yan <ziy@...dia.com>
Subject: Re: [PATCH RFC 21/35] mm/cma: refuse handing out non-contiguous page
 ranges

Hi David,

On Tue, Aug 26, 2025 at 01:04:33PM +0200, David Hildenbrand wrote:
..
> > Just so I can better understand the problem being fixed, I guess you can have
> > two consecutive pfns with non-consecutive associated struct page if you have two
> > adjacent memory sections spanning the same physical memory region, is that
> > correct?
> 
> Exactly. Essentially on SPARSEMEM without SPARSEMEM_VMEMMAP it is not
> guaranteed that
> 
> 	pfn_to_page(pfn + 1) == pfn_to_page(pfn) + 1
> 
> when we cross memory section boundaries.
> 
> It can be the case for early boot memory if we allocated consecutive areas
> from memblock when allocating the memmap (struct pages) per memory section,
> but it's not guaranteed.

Thank you for the explanation, but I'm a bit confused by the last paragraph. I
think what you're saying is that we can also have the reverse problem, where
consecutive struct page * represent non-consecutive pfns, because memmap
allocations happened to return consecutive virtual addresses, is that right?

If that's correct, I don't think that's the case for CMA, which deals out
contiguous physical memory. Or were you just trying to explain the other side of
the problem, and I'm just overthinking it?

Thanks,
Alex