lkml.org 
[lkml]   [2022]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2] mm/swap: fix SWP_PFN_BITS with CONFIG_PHYS_ADDR_T_64BIT on 32bit
From
On 07.12.22 23:40, Yang Shi wrote:
> On Tue, Dec 6, 2022 at 2:57 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> We use "unsigned long" to store a PFN in the kernel and phys_addr_t to
>> store a physical address.
>>
>> On a 64bit system, both are 64bit wide. However, on a 32bit system, the
>> latter might be 64bit wide. This is, for example, the case on x86 with
>> PAE: phys_addr_t and PTEs are 64bit wide, while "unsigned long" only
>> spans 32bit.
>>
>> The current definition of SWP_PFN_BITS without MAX_PHYSMEM_BITS misses
>> that case, and assumes that the maximum PFN is limited by an 32bit
>> phys_addr_t. This implies, that SWP_PFN_BITS will currently only be able to
>> cover 4 GiB - 1 on any 32bit system with 4k page size, which is wrong.
>
> Thanks for debugging this. IIUC this means even swap is actually
> broken on x86_32 + PAE?

I saw all different kinds of issues while testing debugging without this
patch, but they might just be a fallout from previous page migration/THP
splitting issues.

I think swap should be fine, because SWP_PFN_BITS only affects
swp_offset_pfn(): only used when is_pfn_swap_entry()==true.

Thanks!

--
Thanks,

David / dhildenb

\
 
 \ /
  Last update: 2022-12-08 09:44    [W:0.247 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site