Virtualization - Jul 2021 - [PATCH v1 1/4] mm/memory_hotplug: use "unsigned long" for PFN in zone_for_pfn_range()

On 14.07.21 22:13, Heiko Carstens wrote:
> On Mon, Jul 12, 2021 at 02:40:49PM +0200, David Hildenbrand wrote:
>> Checkpatch complained on a follow-up patch that we are using
"unsigned"
>> here, which defaults to "unsigned int" and checkpatch is
correct.
>>
>> Use "unsigned long" instead, just as we do in other places
when handling
>> PFNs. This can bite us once we have physical addresses in the range of
>> multiple TB.
>>
>> Fixes: e5e689302633 ("mm, memory_hotplug: display allowed zones in
the preferred ordering")
>> Signed-off-by: David Hildenbrand <david at redhat.com>
>> ---
>>   include/linux/memory_hotplug.h | 4 ++--
>>   mm/memory_hotplug.c            | 4 ++--
>>   2 files changed, 4 insertions(+), 4 deletions(-)
> 
> I'd propose to add Cc: <stable at vger.kernel.org> since I
actually had
> the fun to try to debug something like this a couple of years ago:
> 6cdb18ad98a4 ("mm/vmstat: fix overflow in mod_zone_page_state()")
> 
Good point, and thinking again what can go wrong, I tend to agree. We 
are trying to keep zones contiguous and it could happen that we end up 
with something like ZONE_DMA here (via default_kernel_zone_for_pfn()) 
and would consequently online something to ZONE_DMA that doesn't belong 
there, resulting in crashes.

@Andrew can you add  Cc: <stable at vger.kernel.org> and

"As we will search for a fitting zone using the wrong pfn, we might end 
up onlining memory to one of the special kernel zones, such as ZONE_DMA, 
which can end badly as the onlined memory does not satisfy properties of 
these zones."

Thanks Heiko!

-- 
Thanks,

David / dhildenb

On Thu, 15 Jul 2021 11:42:21 +0200 David Hildenbrand <david at redhat.com>
wrote:
> > I'd propose to add Cc: <stable at vger.kernel.org> since I
actually had
> > the fun to try to debug something like this a couple of years ago:
> > 6cdb18ad98a4 ("mm/vmstat: fix overflow in
mod_zone_page_state()")
> > 
> 
> Good point, and thinking again what can go wrong, I tend to agree. We 
> are trying to keep zones contiguous and it could happen that we end up 
> with something like ZONE_DMA here (via default_kernel_zone_for_pfn()) 
> and would consequently online something to ZONE_DMA that doesn't belong
> there, resulting in crashes.
> 
> @Andrew can you add  Cc: <stable at vger.kernel.org> and
> 
> "As we will search for a fitting zone using the wrong pfn, we might
end
> up onlining memory to one of the special kernel zones, such as ZONE_DMA, 
> which can end badly as the onlined memory does not satisfy properties of 
> these zones."
Yep, all done.