Re: [PATCH] mm, page_alloc: check pfn is valid before moving to freelist

[Mike Rapoport <rppt@linux.ibm.com>]

On Mon, Apr 18, 2022 at 03:32:21PM -0700, Sudarshan Rajagopalan wrote:
> On 4/18/2022 12:24 AM, Mike Rapoport wrote:
> > On Fri, Apr 15, 2022 at 02:30:52AM +0530, Sudarshan Rajagopalan wrote:
> > > On 4/14/2022 2:18 AM, Mike Rapoport wrote:
> > >
> > > We have a feature where we carve out some portion of memory in RAM partition
> > > table, hence we see such base addresses here.
> > >
> > Cannot the firmware align that portion at some sensible boundary?
> > Or at least report the carved out range as "reserved" (and maybe NOMAP)
> > rather than as hole?
> 
> We can have the firmware or ABL align the address to next pageblock size
> boundary. This would simple mean loosing few MBs of memory with alignment.
> Same with making them as "reserved" with "nomap".

Reserved and nomap do not have to be aligned and there will be a valid
struct page for such regions.

Still, the kernel should be able to cope with firmware oddities so a fix
for 5.15 is still needed.
 
> > That said, your patch will not fix anything in the current kernel because
> > the issue should not happen there, right?
> 
> Yes, the issue seems to be fixed in latest kernel version with the patches
> to drop arm64 pfn_valid. But the core issue is present on previous kernel
> versions with the scenario explained. Any procedure to have this fixed on
> 5.15 kernel?
>
> > I'd suggest backporting a9c38c5d267c ("dma-mapping: remove bogus test for
> > pfn_valid from dma_map_resource") and 3de360c3fdb3 ("arm64/mm: drop
> > HAVE_ARCH_PFN_VALID") to 5.15.
>
> The issue is not seen with these patches backported. Not sure of the
> procedure to send patches for 5.15 kernel, but can we have them backported
> to 5.15?

Please look at Documentation/process/stable-kernel-rules.rst for
explanation how to send patches to stable kernels. 

-- 
Sincerely yours,
Mike.