[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <878qhxo9lo.fsf@toke.dk>
Date: Mon, 29 Sep 2025 12:07:31 +0200
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Helge Deller <deller@....de>, Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>, Lorenzo Stoakes
<lorenzo.stoakes@...cle.com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, Suren
Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, Jesper
Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas
<ilias.apalodimas@...aro.org>, Mina Almasry <almasrymina@...gle.com>,
Jakub Kicinski <kuba@...nel.org>
Cc: Helge Deller <deller@...nel.org>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, linux-mm@...ck.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net] page_pool: Fix PP_MAGIC_MASK to avoid crashing on
some 32-bit arches
Helge Deller <deller@....de> writes:
> On 9/26/25 13:38, Toke Høiland-Jørgensen wrote:
>> Helge reported that the introduction of PP_MAGIC_MASK let to crashes on
>> boot on his 32-bit parisc machine. The cause of this is the mask is set
>> too wide, so the page_pool_page_is_pp() incurs false positives which
>> crashes the machine.
>>
>> Just disabling the check in page_pool_is_pp() will lead to the page_pool
>> code itself malfunctioning; so instead of doing this, this patch changes
>> the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel
>> pointers for page_pool-tagged pages.
>>
>> The fix relies on the kernel pointers that alias with the pp_magic field
>> always being above PAGE_OFFSET. With this assumption, we can use the
>> lowest bit of the value of PAGE_OFFSET as the upper bound of the
>> PP_DMA_INDEX_MASK, which should avoid the false positives.
>>
>> Because we cannot rely on PAGE_OFFSET always being a compile-time
>> constant, nor on it always being >0, we fall back to disabling the
>> dma_index storage when there are no bits available. This leaves us in
>> the situation we were in before the patch in the Fixes tag, but only on
>> a subset of architecture configurations. This seems to be the best we
>> can do until the transition to page types in complete for page_pool
>> pages.
>>
>> Link: https://lore.kernel.org/all/aMNJMFa5fDalFmtn@p100/
>> Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>> ---
>> Sorry for the delay on getting this out. I have only compile-tested it,
>> since I don't have any hardware that triggers the original bug. Helge, I'm
>> hoping you can take it for a spin?
>
> I can't comment if the patch is otherwise ok, but it does
> indeed fixes the boot problem for me, so:
>
> Tested-by: Helge Deller <deller@....de>
Great, thanks for testing :)
> Btw, this can easily be tested with qemu:
> ./qemu-system-hppa -kernel vmlinux -nographic -serial mon:stdio
Ah, neat, thank you for the pointer!
> If the patch is accepted, can you add the CC-stable tag, so that
> it gets pushed down to kernel 6.15+ too?
I find that networking patches make it to the stable trees based on the
Fixes tags, but I'll try to keep an eye on it just to make sure. I can
also add the Cc if I need to respin for some other reason.
-Toke
Powered by blists - more mailing lists