Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-31 Thread Jiri Slaby 
On 08/31/2018, 02:10 PM, Pasha Tatashin wrote:
> Thanks Jiri, I am now able to reproduce it with your new config.
> 
> I have tried yesterday to enable sparsemem and deferred_struct_init on
> x86_32, and that kernel booted fine, there must be something else in
> your config that helps to trigger this problem. I am studying it now.
> 
> [0.051245] Initializing CPU#0
> [0.051682] Initializing HighMem for node 0 (000367fe:0007ffe0)
> [0.067499] BUG: unable to handle kernel NULL pointer dereference at
> 0028
> [0.068452] *pdpt =  *pde = f000ff53f000ff53
> [0.069105] Oops:  [#1] PREEMPT SMP PTI
> [0.069595] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.19.0-rc1-pae_pt_jiri #1
> [0.070382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.11.0-20171110_100015-anatol 04/01/2014
> [0.071545] EIP: free_unref_page_prepare.part.70+0x2c/0x50
> [0.072178] Code: 19 e9 ff 89 d1 55 c1 ea 11 c1 e9 07 8b 14 d5 44 52
> fd d6 81 e1 fc 03 00 00 89 e5 56 53 89 cb be 1d 00 00 00 c1 eb 05 83 e1
> 1f <8b> 14 9a 29 ce 89 f1 d3 ea 83 e2 07 89 50 10 b8 01 00 00 00 5b 5e
> [0.074296] EAX: f4cfa000 EBX: 000a ECX: 0010 EDX: 
> [0.075005] ESI: 001d EDI: 0007ffe0 EBP: d6d41ed0 ESP: d6d41ec8
> [0.075714] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210002
> [0.076508] CR0: 80050033 CR2: 0028 CR3: 16f2 CR4: 000406b0
> [0.077242] DR0:  DR1:  DR2:  DR3: 
> [0.077934] DR6: fffe0ff0 DR7: 0400
> [0.078380] Call Trace:
> [0.078670]  free_unref_page+0x3a/0x90
> [0.079136]  __free_pages+0x25/0x30
> [0.079533]  free_highmem_page+0x1e/0x50
> [0.079978]  add_highpages_with_active_regions+0xd1/0x11f
> [0.080592]  set_highmem_pages_init+0x67/0x7d
> [0.081076]  mem_init+0x30/0x1fc

page_to_pfn(pfn_to_page(pfn)) != pfn with my .config on pfns >= 0x6:

[0.157667] add_highpages_with_active_regions: pfn=5fffb pg=f55f9f4c
pfn(pg(pfn)=5fffb sec=2
[0.159231] add_highpages_with_active_regions: pfn=5fffc pg=f55f9f70
pfn(pg(pfn)=5fffc sec=2
[0.161020] add_highpages_with_active_regions: pfn=5fffd pg=f55f9f94
pfn(pg(pfn)=5fffd sec=2
[0.163149] add_highpages_with_active_regions: pfn=5fffe pg=f55f9fb8
pfn(pg(pfn)=5fffe sec=2
[0.165204] add_highpages_with_active_regions: pfn=5 pg=f55f9fdc
pfn(pg(pfn)=5 sec=2
[0.167216] add_highpages_with_active_regions: pfn=6 pg=f4cfa000
pfn(pg(pfn)=c716a800 sec=3

So add_highpages_with_active_regions passes down page to
free_highmem_page and later, free_unref_page does page_to_pfn(page) and
__get_pfnblock_flags_mask operates on this modified pfn leading to crash
– __pfn_to_section(pfn)->pageblock_flags is NULL!

Note that __pfn_to_section(pfn)->pageblock_flags on the original pfn
returns a valid bitmap.

thanks,
-- 
js
suse labs

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-31 Thread Pasha Tatashin 
Thanks Jiri, I am now able to reproduce it with your new config.

I have tried yesterday to enable sparsemem and deferred_struct_init on
x86_32, and that kernel booted fine, there must be something else in
your config that helps to trigger this problem. I am studying it now.

[0.051245] Initializing CPU#0
[0.051682] Initializing HighMem for node 0 (000367fe:0007ffe0)
[0.067499] BUG: unable to handle kernel NULL pointer dereference at
0028
[0.068452] *pdpt =  *pde = f000ff53f000ff53
[0.069105] Oops:  [#1] PREEMPT SMP PTI
[0.069595] CPU: 0 PID: 0 Comm: swapper Not tainted
4.19.0-rc1-pae_pt_jiri #1
[0.070382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[0.071545] EIP: free_unref_page_prepare.part.70+0x2c/0x50
[0.072178] Code: 19 e9 ff 89 d1 55 c1 ea 11 c1 e9 07 8b 14 d5 44 52
fd d6 81 e1 fc 03 00 00 89 e5 56 53 89 cb be 1d 00 00 00 c1 eb 05 83 e1
1f <8b> 14 9a 29 ce 89 f1 d3 ea 83 e2 07 89 50 10 b8 01 00 00 00 5b 5e
[0.074296] EAX: f4cfa000 EBX: 000a ECX: 0010 EDX: 
[0.075005] ESI: 001d EDI: 0007ffe0 EBP: d6d41ed0 ESP: d6d41ec8
[0.075714] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210002
[0.076508] CR0: 80050033 CR2: 0028 CR3: 16f2 CR4: 000406b0
[0.077242] DR0:  DR1:  DR2:  DR3: 
[0.077934] DR6: fffe0ff0 DR7: 0400
[0.078380] Call Trace:
[0.078670]  free_unref_page+0x3a/0x90
[0.079136]  __free_pages+0x25/0x30
[0.079533]  free_highmem_page+0x1e/0x50
[0.079978]  add_highpages_with_active_regions+0xd1/0x11f
[0.080592]  set_highmem_pages_init+0x67/0x7d
[0.081076]  mem_init+0x30/0x1fc
[0.081434]  start_kernel+0x1cc/0x44c
[0.081874]  i386_start_kernel+0x98/0x9c
[0.082401]  startup_32_smp+0x164/0x168
[0.082873] Modules linked in:
[0.083228] CR2: 0028
[0.083606] ---[ end trace a5990d9ace2ec990 ]---
[0.084128] EIP: free_unref_page_prepare.part.70+0x2c/0x50
[0.084747] Code: 19 e9 ff 89 d1 55 c1 ea 11 c1 e9 07 8b 14 d5 44 52
fd d6 81 e1 fc 03 00 00 89 e5 56 53 89 cb be 1d 00 00 00 c1 eb 05 83 e1
1f <8b> 14 9a 29 ce 89 f1 d3 ea 83 e2 07 89 50 10 b8 01 00 00 00 5b 5e
[0.086874] EAX: f4cfa000 EBX: 000a ECX: 0010 EDX: 
[0.087581] ESI: 001d EDI: 0007ffe0 EBP: d6d41ed0 ESP: d6f27efc
[0.088287] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210002
[0.089139] CR0: 80050033 CR2: 0028 CR3: 16f2 CR4: 000406b0
[0.089850] DR0:  DR1:  DR2:  DR3: 
[0.090557] DR6: fffe0ff0 DR7: 0400
[0.090992] Kernel panic - not syncing: Attempted to kill the idle task!


Pavel

On 8/31/18 7:29 AM, Jiri Slaby wrote:
> On 08/31/2018, 01:26 PM, Jiri Slaby wrote:
>> On 08/30/2018, 05:45 PM, Pasha Tatashin wrote:
>>> Hi Jiri,
>>>
>>> I believe this bug is fixed with this change:
>>>
>>> d39f8fb4b7776dcb09ec3bf7a321547083078ee3
>>> mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
>>
>> Hi,
>>
>> it only shifted. Enabling only SPARSEMEM works fine, enabling also
>> DEFERRED_STRUCT_PAGE_INIT doesn't even boot – immediately reboots
>> (config attached).
> 
> Wow, earlyprintk is up at the moment of crash already:
> [0.00] Linux version 4.19.0-rc1-pae (jslaby@kunlun) (gcc version
> 4.8.5 (SUSE Linux)) #4 SMP PREEMPT Fri Aug 31 13:18:33 CEST 2018
> [0.00] x86/fpu: x87 FPU will use FXSAVE
> [0.00] BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
> reserved
> [0.00] BIOS-e820: [mem 0x000f-0x000f]
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0x7cfd] usable
> [0.00] BIOS-e820: [mem 0x7cfe-0x7cff]
> reserved
> [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff]
> reserved
> [0.00] BIOS-e820: [mem 0xfffc-0x]
> reserved
> [0.00] bootconsole [earlyser0] enabled
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.8 present.
> [0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.0.0-prebuilt.qemu-project.org 04/01/2014
> [0.00] Hypervisor detected: KVM
> [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
> [0.02] kvm-clock: cpu 0, msr 1d12c001, primary cpu clock
> [0.02] kvm-clock: using sched offset of 1597117996 cycles
> [0.001395] clocksource: kvm-clock: mask: 0x
> max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
> [0.006245] tsc: Detected 2808.000 MHz processor
> [0.010055] last_pfn = 0x7cfe0 max_arch_pfn = 0x100
> [0.011483] x86/PAT: PAT not supported by CPU.
> [0.012580] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC-
> UC
> [

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-31 Thread Jiri Slaby 
On 08/31/2018, 01:26 PM, Jiri Slaby wrote:
> On 08/30/2018, 05:45 PM, Pasha Tatashin wrote:
>> Hi Jiri,
>>
>> I believe this bug is fixed with this change:
>>
>> d39f8fb4b7776dcb09ec3bf7a321547083078ee3
>> mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM
> 
> Hi,
> 
> it only shifted. Enabling only SPARSEMEM works fine, enabling also
> DEFERRED_STRUCT_PAGE_INIT doesn't even boot – immediately reboots
> (config attached).

Wow, earlyprintk is up at the moment of crash already:
[0.00] Linux version 4.19.0-rc1-pae (jslaby@kunlun) (gcc version
4.8.5 (SUSE Linux)) #4 SMP PREEMPT Fri Aug 31 13:18:33 CEST 2018
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0x7cfd] usable
[0.00] BIOS-e820: [mem 0x7cfe-0x7cff]
reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff]
reserved
[0.00] BIOS-e820: [mem 0xfffc-0x]
reserved
[0.00] bootconsole [earlyser0] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.0.0-prebuilt.qemu-project.org 04/01/2014
[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.02] kvm-clock: cpu 0, msr 1d12c001, primary cpu clock
[0.02] kvm-clock: using sched offset of 1597117996 cycles
[0.001395] clocksource: kvm-clock: mask: 0x
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.006245] tsc: Detected 2808.000 MHz processor
[0.010055] last_pfn = 0x7cfe0 max_arch_pfn = 0x100
[0.011483] x86/PAT: PAT not supported by CPU.
[0.012580] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC-
UC
[0.020644] found SMP MP-table at [mem 0x000f5d20-0x000f5d2f] mapped
at [(ptrval)]
[0.023528] Scanning 1 areas for low memory corruption
[0.025047] ACPI: Early table checksum verification disabled
[0.026581] ACPI: RSDP 0x000F5B40 14 (v00 BOCHS )
[0.028031] ACPI: RSDT 0x7CFE157C 30 (v01 BOCHS  BXPCRSDT
0001 BXPC 0001)
[0.029996] ACPI: FACP 0x7CFE1458 74 (v01 BOCHS  BXPCFACP
0001 BXPC 0001)
[0.032234] ACPI: DSDT 0x7CFE0040 001418 (v01 BOCHS  BXPCDSDT
0001 BXPC 0001)
[0.034662] ACPI: FACS 0x7CFE 40
[0.036126] ACPI: APIC 0x7CFE14CC 78 (v01 BOCHS  BXPCAPIC
0001 BXPC 0001)
[0.038235] ACPI: HPET 0x7CFE1544 38 (v01 BOCHS  BXPCHPET
0001 BXPC 0001)
[0.040373] No NUMA configuration found
[0.041407] Faking a node at [mem 0x-0x7cfd]
[0.043306] NODE_DATA(0) allocated [mem 0x367fc000-0x367fcfff]
[0.044958] 1127MB HIGHMEM available.
[0.045940] 871MB LOWMEM available.
[0.046978]   mapped low ram: 0 - 367fe000
[0.048200]   low ram: 0 - 367fe000
[0.050830] Zone ranges:
[0.051625]   DMA  [mem 0x1000-0x00ff]
[0.053295]   Normal   [mem 0x0100-0x367fdfff]
[0.054921]   HighMem  [mem 0x367fe000-0x7cfd]
[0.056408] Movable zone start for each node
[0.057452] Early memory node ranges
[0.058377]   node   0: [mem 0x1000-0x0009efff]
[0.059946]   node   0: [mem 0x0010-0x7cfd]
[0.061825] Reserved but unavailable: 12418 pages
[0.061828] Initmem setup node 0 [mem
0x1000-0x7cfd]
[0.074252] Using APIC driver default
[0.075615] ACPI: PM-Timer IO Port: 0x608
[0.076574] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[0.077995] IOAPIC[0]: apic_id 0, version 17, address 0xfec0, GSI
0-23
[0.079610] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.08] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[0.082786] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[0.084297] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[0.085933] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[0.087729] Using ACPI (MADT) for SMP configuration information
[0.089119] ACPI: HPET id: 0x8086a201 base: 0xfed0
[0.090351] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[0.091561] PM: Registered nosave memory: [mem 0x-0x0fff]
[0.093361] PM: Registered nosave memory: [mem 0x0009f000-0x0009]
[0.096382] PM: Registered nosave memory: [mem 0x000a-0x000e]
[0.098130] PM: Registered nosave memory: [mem 0x000f-0x000f]
[0.099729] [mem 0x7d00-0xfeffbfff]

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-30 Thread Pasha Tatashin 
Hi Jiri,

I believe this bug is fixed with this change:

d39f8fb4b7776dcb09ec3bf7a321547083078ee3
mm: make DEFERRED_STRUCT_PAGE_INIT explicitly depend on SPARSEMEM

I am not able to reproduce this problem on x86-32.

Pavel

On 8/30/18 10:35 AM, Pavel Tatashin wrote:
> Thank you Jiri, I am studying it.
> 
> Pavel
> 
> On 8/24/18 3:44 AM, Jiri Slaby wrote:
>> pasha.tatas...@oracle.com -> pavel.tatas...@microsoft.com
>>
>> due to
>>  550 5.1.1 Unknown recipient address.
>>
>>
>> On 08/24/2018, 09:32 AM, Jiri Slaby wrote:
>>> On 06/19/2018, 09:56 PM, Pavel Tatashin wrote:
 On Tue, Jun 19, 2018 at 9:50 AM Pavel Tatashin
  wrote:
>
> On Sat, Jun 16, 2018 at 4:04 AM Jiri Slaby  wrote:
>>
>> On 11/21/2017, 08:24 AM, Michal Hocko wrote:
>>> On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
 There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
 as all the page initialization code is in common code.

 Also, there is no need to depend on MEMORY_HOTPLUG, as initialization 
 code
 does not really use hotplug memory functionality. So, we can remove 
 this
 requirement as well.

 This patch allows to use deferred struct page initialization on all
 platforms with memblock allocator.

 Tested on x86, arm64, and sparc. Also, verified that code compiles on
 PPC with CONFIG_MEMORY_HOTPLUG disabled.
>>>
>>> There is slight risk that we will encounter corner cases on some
>>> architectures with weird memory layout/topology
>>
>> Which x86_32-pae seems to be. Many bad page state errors are emitted
>> during boot when this patch is applied:
>
> Hi Jiri,
>
> Thank you for reporting this bug.
>
> Because 32-bit systems are limited in the maximum amount of physical
> memory, they don't need deferred struct pages. So, we can add depends
> on 64BIT to DEFERRED_STRUCT_PAGE_INIT in mm/Kconfig.
>
> However, before we do this, I want to try reproducing this problem and
> root cause it, as it might expose a general problem that is not 32-bit
> specific.

 Hi Jiri,

 Could you please attach your config and full qemu arguments that you
 used to reproduce this bug.
>>>
>>> Hi,
>>>
>>> I seem I never replied. Attaching .config and the qemu cmdline:
>>> $ qemu-kvm -m 2000 -hda /dev/null -kernel bzImage
>>>
>>> "-m 2000" is important to reproduce.
>>>
>>> If I disable CONFIG_DEFERRED_STRUCT_PAGE_INIT (which the patch allowed
>>> to enable), the error goes away, of course.
>>>
>>> thanks,
>>>
>>
>>

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-30 Thread Pasha Tatashin 
Thank you Jiri, I am studying it.

Pavel

On 8/24/18 3:44 AM, Jiri Slaby wrote:
> pasha.tatas...@oracle.com -> pavel.tatas...@microsoft.com
> 
> due to
>  550 5.1.1 Unknown recipient address.
> 
> 
> On 08/24/2018, 09:32 AM, Jiri Slaby wrote:
>> On 06/19/2018, 09:56 PM, Pavel Tatashin wrote:
>>> On Tue, Jun 19, 2018 at 9:50 AM Pavel Tatashin
>>>  wrote:

 On Sat, Jun 16, 2018 at 4:04 AM Jiri Slaby  wrote:
>
> On 11/21/2017, 08:24 AM, Michal Hocko wrote:
>> On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
>>> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
>>> as all the page initialization code is in common code.
>>>
>>> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization 
>>> code
>>> does not really use hotplug memory functionality. So, we can remove this
>>> requirement as well.
>>>
>>> This patch allows to use deferred struct page initialization on all
>>> platforms with memblock allocator.
>>>
>>> Tested on x86, arm64, and sparc. Also, verified that code compiles on
>>> PPC with CONFIG_MEMORY_HOTPLUG disabled.
>>
>> There is slight risk that we will encounter corner cases on some
>> architectures with weird memory layout/topology
>
> Which x86_32-pae seems to be. Many bad page state errors are emitted
> during boot when this patch is applied:

 Hi Jiri,

 Thank you for reporting this bug.

 Because 32-bit systems are limited in the maximum amount of physical
 memory, they don't need deferred struct pages. So, we can add depends
 on 64BIT to DEFERRED_STRUCT_PAGE_INIT in mm/Kconfig.

 However, before we do this, I want to try reproducing this problem and
 root cause it, as it might expose a general problem that is not 32-bit
 specific.
>>>
>>> Hi Jiri,
>>>
>>> Could you please attach your config and full qemu arguments that you
>>> used to reproduce this bug.
>>
>> Hi,
>>
>> I seem I never replied. Attaching .config and the qemu cmdline:
>> $ qemu-kvm -m 2000 -hda /dev/null -kernel bzImage
>>
>> "-m 2000" is important to reproduce.
>>
>> If I disable CONFIG_DEFERRED_STRUCT_PAGE_INIT (which the patch allowed
>> to enable), the error goes away, of course.
>>
>> thanks,
>>
> 
>

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-08-24 Thread Jiri Slaby 
pasha.tatas...@oracle.com -> pavel.tatas...@microsoft.com

due to
 550 5.1.1 Unknown recipient address.


On 08/24/2018, 09:32 AM, Jiri Slaby wrote:
> On 06/19/2018, 09:56 PM, Pavel Tatashin wrote:
>> On Tue, Jun 19, 2018 at 9:50 AM Pavel Tatashin
>>  wrote:
>>>
>>> On Sat, Jun 16, 2018 at 4:04 AM Jiri Slaby  wrote:

 On 11/21/2017, 08:24 AM, Michal Hocko wrote:
> On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
>> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
>> as all the page initialization code is in common code.
>>
>> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization 
>> code
>> does not really use hotplug memory functionality. So, we can remove this
>> requirement as well.
>>
>> This patch allows to use deferred struct page initialization on all
>> platforms with memblock allocator.
>>
>> Tested on x86, arm64, and sparc. Also, verified that code compiles on
>> PPC with CONFIG_MEMORY_HOTPLUG disabled.
>
> There is slight risk that we will encounter corner cases on some
> architectures with weird memory layout/topology

 Which x86_32-pae seems to be. Many bad page state errors are emitted
 during boot when this patch is applied:
>>>
>>> Hi Jiri,
>>>
>>> Thank you for reporting this bug.
>>>
>>> Because 32-bit systems are limited in the maximum amount of physical
>>> memory, they don't need deferred struct pages. So, we can add depends
>>> on 64BIT to DEFERRED_STRUCT_PAGE_INIT in mm/Kconfig.
>>>
>>> However, before we do this, I want to try reproducing this problem and
>>> root cause it, as it might expose a general problem that is not 32-bit
>>> specific.
>>
>> Hi Jiri,
>>
>> Could you please attach your config and full qemu arguments that you
>> used to reproduce this bug.
> 
> Hi,
> 
> I seem I never replied. Attaching .config and the qemu cmdline:
> $ qemu-kvm -m 2000 -hda /dev/null -kernel bzImage
> 
> "-m 2000" is important to reproduce.
> 
> If I disable CONFIG_DEFERRED_STRUCT_PAGE_INIT (which the patch allowed
> to enable), the error goes away, of course.
> 
> thanks,
> 


-- 
js
suse labs

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-06-19 Thread Pavel Tatashin 
On Tue, Jun 19, 2018 at 9:50 AM Pavel Tatashin
 wrote:
>
> On Sat, Jun 16, 2018 at 4:04 AM Jiri Slaby  wrote:
> >
> > On 11/21/2017, 08:24 AM, Michal Hocko wrote:
> > > On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
> > >> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> > >> as all the page initialization code is in common code.
> > >>
> > >> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization 
> > >> code
> > >> does not really use hotplug memory functionality. So, we can remove this
> > >> requirement as well.
> > >>
> > >> This patch allows to use deferred struct page initialization on all
> > >> platforms with memblock allocator.
> > >>
> > >> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> > >> PPC with CONFIG_MEMORY_HOTPLUG disabled.
> > >
> > > There is slight risk that we will encounter corner cases on some
> > > architectures with weird memory layout/topology
> >
> > Which x86_32-pae seems to be. Many bad page state errors are emitted
> > during boot when this patch is applied:
>
> Hi Jiri,
>
> Thank you for reporting this bug.
>
> Because 32-bit systems are limited in the maximum amount of physical
> memory, they don't need deferred struct pages. So, we can add depends
> on 64BIT to DEFERRED_STRUCT_PAGE_INIT in mm/Kconfig.
>
> However, before we do this, I want to try reproducing this problem and
> root cause it, as it might expose a general problem that is not 32-bit
> specific.

Hi Jiri,

Could you please attach your config and full qemu arguments that you
used to reproduce this bug.

Thank you,
Pavel


>
> Thank you,
> Pavel

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-06-19 Thread Pavel Tatashin 
On Sat, Jun 16, 2018 at 4:04 AM Jiri Slaby  wrote:
>
> On 11/21/2017, 08:24 AM, Michal Hocko wrote:
> > On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
> >> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> >> as all the page initialization code is in common code.
> >>
> >> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code
> >> does not really use hotplug memory functionality. So, we can remove this
> >> requirement as well.
> >>
> >> This patch allows to use deferred struct page initialization on all
> >> platforms with memblock allocator.
> >>
> >> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> >> PPC with CONFIG_MEMORY_HOTPLUG disabled.
> >
> > There is slight risk that we will encounter corner cases on some
> > architectures with weird memory layout/topology
>
> Which x86_32-pae seems to be. Many bad page state errors are emitted
> during boot when this patch is applied:

Hi Jiri,

Thank you for reporting this bug.

Because 32-bit systems are limited in the maximum amount of physical
memory, they don't need deferred struct pages. So, we can add depends
on 64BIT to DEFERRED_STRUCT_PAGE_INIT in mm/Kconfig.

However, before we do this, I want to try reproducing this problem and
root cause it, as it might expose a general problem that is not 32-bit
specific.

Thank you,
Pavel

Re: [PATCH v1] mm: relax deferred struct page requirements

2018-06-16 Thread Jiri Slaby 
On 11/21/2017, 08:24 AM, Michal Hocko wrote:
> On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
>> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
>> as all the page initialization code is in common code.
>>
>> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code
>> does not really use hotplug memory functionality. So, we can remove this
>> requirement as well.
>>
>> This patch allows to use deferred struct page initialization on all
>> platforms with memblock allocator.
>>
>> Tested on x86, arm64, and sparc. Also, verified that code compiles on
>> PPC with CONFIG_MEMORY_HOTPLUG disabled.
> 
> There is slight risk that we will encounter corner cases on some
> architectures with weird memory layout/topology

Which x86_32-pae seems to be. Many bad page state errors are emitted
during boot when this patch is applied:
BUG: Bad page state in process swapper  pfn:3c01c
page:f566c3f0 count:0 mapcount:1 mapping: index:0x0
flags: 0x0()
raw:      0100 0200 
raw: 
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: GB
4.17.1-4.gdf028bb-pae #1 openSUSE Tumbleweed (unreleased)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
 dump_stack+0x7d/0xbd
 bad_page.cold.111+0x90/0xc7
 free_pages_check_bad+0x52/0x70
 free_pcppages_bulk+0x37d/0x570
 free_unref_page_commit+0x9a/0xc0
 free_unref_page+0x6a/0xa0
 __free_pages+0x17/0x30
 free_highmem_page+0x1e/0x50
 add_highpages_with_active_regions+0xd6/0x113
 set_highmem_pages_init+0x67/0x7d
 mem_init+0x23/0x1d9
 start_kernel+0x1c2/0x437
 i386_start_kernel+0x98/0x9c
 startup_32_smp+0x164/0x168

free_pages_check_bad expects mapcount == -1, but it is 1 with this patch.

Reverting the patch makes the BUGs go away -- the config diff is then:
@@ -617,7 +617,7 @@
 # CONFIG_PGTABLE_MAPPING is not set
 # CONFIG_ZSMALLOC_STAT is not set
 CONFIG_GENERIC_EARLY_IOREMAP=y
-CONFIG_DEFERRED_STRUCT_PAGE_INIT=y
+CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
 # CONFIG_IDLE_PAGE_TRACKING is not set
 CONFIG_FRAME_VECTOR=y
 # CONFIG_PERCPU_STATS is not set

>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -148,7 +148,6 @@ config PPC
>>  select ARCH_MIGHT_HAVE_PC_PARPORT
>>  select ARCH_MIGHT_HAVE_PC_SERIO
>>  select ARCH_SUPPORTS_ATOMIC_RMW
>> -select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>>  select ARCH_USE_BUILTIN_BSWAP
>>  select ARCH_USE_CMPXCHG_LOCKREF if PPC64
>>  select ARCH_WANT_IPC_PARSE_VERSION
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index 863a62a6de3c..525c2e3df6f5 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -108,7 +108,6 @@ config S390
>>  select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
>>  select ARCH_SAVE_PAGE_KEYS if HIBERNATION
>>  select ARCH_SUPPORTS_ATOMIC_RMW
>> -select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>>  select ARCH_SUPPORTS_NUMA_BALANCING
>>  select ARCH_USE_BUILTIN_BSWAP
>>  select ARCH_USE_CMPXCHG_LOCKREF
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index df3276d6bfe3..00a5446de394 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -69,7 +69,6 @@ config X86
>>  select ARCH_MIGHT_HAVE_PC_PARPORT
>>  select ARCH_MIGHT_HAVE_PC_SERIO
>>  select ARCH_SUPPORTS_ATOMIC_RMW
>> -select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>>  select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
>>  select ARCH_USE_BUILTIN_BSWAP
>>  select ARCH_USE_QUEUED_RWLOCKS
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 9c4b80c2..c6bd0309ce7a 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -639,15 +639,10 @@ config MAX_STACK_SIZE_MB
>>  
>>A sane initial value is 80 MB.
>>  
>> -# For architectures that support deferred memory initialisation
>> -config ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>> -bool
>> -
>>  config DEFERRED_STRUCT_PAGE_INIT
>>  bool "Defer initialisation of struct pages to kthreads"
>>  default n
>> -depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>> -depends on NO_BOOTMEM && MEMORY_HOTPLUG
>> +depends on NO_BOOTMEM
>>  depends on !FLATMEM
>>  help
>>Ordinarily all struct pages are initialised during early boot in a

thanks,
-- 
js
suse labs

Re: [PATCH v1] mm: relax deferred struct page requirements

2017-11-23 Thread Michael Ellerman 
Pavel Tatashin  writes:

> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> as all the page initialization code is in common code.
>
> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code
> does not really use hotplug memory functionality. So, we can remove this
> requirement as well.
>
> This patch allows to use deferred struct page initialization on all
> platforms with memblock allocator.
>
> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> PPC with CONFIG_MEMORY_HOTPLUG disabled.
>
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/powerpc/Kconfig | 1 -
>  arch/s390/Kconfig| 1 -
>  arch/x86/Kconfig | 1 -
>  mm/Kconfig   | 7 +--
>  4 files changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index cb782ac1c35d..1540348691c9 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -148,7 +148,6 @@ config PPC
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
>   select ARCH_SUPPORTS_ATOMIC_RMW
> - select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT

Acked-by: Michael Ellerman 

cheers

Re: [PATCH v1] mm: relax deferred struct page requirements

2017-11-21 Thread Khalid Aziz 
On Thu, 2017-11-16 at 20:46 -0500, Pavel Tatashin wrote:
> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> as all the page initialization code is in common code.
> 
> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization
> code
> does not really use hotplug memory functionality. So, we can remove
> this
> requirement as well.
> 
> This patch allows to use deferred struct page initialization on all
> platforms with memblock allocator.
> 
> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> PPC with CONFIG_MEMORY_HOTPLUG disabled.
> 
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/powerpc/Kconfig | 1 -
>  arch/s390/Kconfig| 1 -
>  arch/x86/Kconfig | 1 -
>  mm/Kconfig   | 7 +--
>  4 files changed, 1 insertion(+), 9 deletions(-)
> 
> 

Looks reasonable to me.

Reviewed-by: Khalid Aziz

Re: [PATCH v1] mm: relax deferred struct page requirements

2017-11-20 Thread Michal Hocko 
On Thu 16-11-17 20:46:01, Pavel Tatashin wrote:
> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> as all the page initialization code is in common code.
> 
> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code
> does not really use hotplug memory functionality. So, we can remove this
> requirement as well.
> 
> This patch allows to use deferred struct page initialization on all
> platforms with memblock allocator.
> 
> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> PPC with CONFIG_MEMORY_HOTPLUG disabled.

There is slight risk that we will encounter corner cases on some
architectures with weird memory layout/topology but we should better
explicitly disable this code rather than make it opt-in so this looks
like an improvement to me.
 
> Signed-off-by: Pavel Tatashin 

Acked-by: Michal Hocko 

> ---
>  arch/powerpc/Kconfig | 1 -
>  arch/s390/Kconfig| 1 -
>  arch/x86/Kconfig | 1 -
>  mm/Kconfig   | 7 +--
>  4 files changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index cb782ac1c35d..1540348691c9 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -148,7 +148,6 @@ config PPC
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
>   select ARCH_SUPPORTS_ATOMIC_RMW
> - select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_CMPXCHG_LOCKREF if PPC64
>   select ARCH_WANT_IPC_PARSE_VERSION
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 863a62a6de3c..525c2e3df6f5 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -108,7 +108,6 @@ config S390
>   select ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE
>   select ARCH_SAVE_PAGE_KEYS if HIBERNATION
>   select ARCH_SUPPORTS_ATOMIC_RMW
> - select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>   select ARCH_SUPPORTS_NUMA_BALANCING
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_CMPXCHG_LOCKREF
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index df3276d6bfe3..00a5446de394 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -69,7 +69,6 @@ config X86
>   select ARCH_MIGHT_HAVE_PC_PARPORT
>   select ARCH_MIGHT_HAVE_PC_SERIO
>   select ARCH_SUPPORTS_ATOMIC_RMW
> - select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
>   select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
>   select ARCH_USE_BUILTIN_BSWAP
>   select ARCH_USE_QUEUED_RWLOCKS
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 9c4b80c2..c6bd0309ce7a 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -639,15 +639,10 @@ config MAX_STACK_SIZE_MB
>  
> A sane initial value is 80 MB.
>  
> -# For architectures that support deferred memory initialisation
> -config ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
> - bool
> -
>  config DEFERRED_STRUCT_PAGE_INIT
>   bool "Defer initialisation of struct pages to kthreads"
>   default n
> - depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
> - depends on NO_BOOTMEM && MEMORY_HOTPLUG
> + depends on NO_BOOTMEM
>   depends on !FLATMEM
>   help
> Ordinarily all struct pages are initialised during early boot in a
> -- 
> 2.15.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v1] mm: relax deferred struct page requirements

2017-11-16 Thread Heiko Carstens 
On Thu, Nov 16, 2017 at 08:46:01PM -0500, Pavel Tatashin wrote:
> There is no need to have ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT,
> as all the page initialization code is in common code.
> 
> Also, there is no need to depend on MEMORY_HOTPLUG, as initialization code
> does not really use hotplug memory functionality. So, we can remove this
> requirement as well.
> 
> This patch allows to use deferred struct page initialization on all
> platforms with memblock allocator.
> 
> Tested on x86, arm64, and sparc. Also, verified that code compiles on
> PPC with CONFIG_MEMORY_HOTPLUG disabled.
> 
> Signed-off-by: Pavel Tatashin 
> ---
>  arch/powerpc/Kconfig | 1 -
>  arch/s390/Kconfig| 1 -
>  arch/x86/Kconfig | 1 -
>  mm/Kconfig   | 7 +--
>  4 files changed, 1 insertion(+), 9 deletions(-)

For s390 the s390 bit:

Acked-by: Heiko Carstens