* [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch
@ 2017-07-31 18:17 Daniel Henrique Barboza
2017-08-01 9:59 ` Michael Ellerman
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Henrique Barboza @ 2017-07-31 18:17 UTC (permalink / raw)
To: linuxppc-dev
Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online
hotplugged memory'") reverted the auto-online feature for pseries due
to problems with LMB removals not updating the device struct properly.
Among other things, this commit made the following change in
arch/powerpc/configs/pseries_defconfig:
@@ -58,7 +58,6 @@ CONFIG_KEXEC_FILE=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTREMOVE=y
-CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
CONFIG_KSM=y
The intent was to disable the option in the defconfig of pseries, since
after that the code doesn't have this support anymore. However, this change
alone isn't enough to prevent situations such as [1], where
distros can enable the option unaware of the consequences of
doing it (e.g. breaking LMB hotplug altogether).
Instead of relying on all distros knowing that pseries can't handle
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch
changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config
unavailable for the PPC64 arch.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380
Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'")
Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
---
mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 48b1af4..a342c77 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE
config MEMORY_HOTPLUG_DEFAULT_ONLINE
bool "Online the newly added memory blocks by default"
default n
- depends on MEMORY_HOTPLUG
+ depends on MEMORY_HOTPLUG && !PPC64
help
This option sets the default policy setting for memory hotplug
onlining policy (/sys/devices/system/memory/auto_online_blocks) which
--
2.9.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch 2017-07-31 18:17 [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch Daniel Henrique Barboza @ 2017-08-01 9:59 ` Michael Ellerman 2017-08-01 14:05 ` Nathan Fontenot 0 siblings, 1 reply; 6+ messages in thread From: Michael Ellerman @ 2017-08-01 9:59 UTC (permalink / raw) To: Daniel Henrique Barboza, linuxppc-dev, nfont Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes: > Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online > hotplugged memory'") reverted the auto-online feature for pseries due > to problems with LMB removals not updating the device struct properly. > Among other things, this commit made the following change in > arch/powerpc/configs/pseries_defconfig: > > @@ -58,7 +58,6 @@ CONFIG_KEXEC_FILE=y > CONFIG_IRQ_ALL_CPUS=y > CONFIG_MEMORY_HOTPLUG=y > CONFIG_MEMORY_HOTREMOVE=y > -CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y > CONFIG_KSM=y > > The intent was to disable the option in the defconfig of pseries, since > after that the code doesn't have this support anymore. It's always polite to Cc the author of a commit you're referring to, so I added Nathan. The intention when we merged that fix was that the auto-online code would be "fixed" to mark the device online. I say "fixed" because it wasn't entirely clear if that was the correct behaviour, though it definitely seemed like it should be. I've lost track of where/if the discussion got to on whether the auto-online code should do that or not. Did anything get resolved? > However, this change > alone isn't enough to prevent situations such as [1], where > distros can enable the option unaware of the consequences of > doing it (e.g. breaking LMB hotplug altogether). > > Instead of relying on all distros knowing that pseries can't handle > CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch > changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config > unavailable for the PPC64 arch. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380 > > Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'") > Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> > --- > mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I don't own that file, so we at least need an Ack from the mm folks. cheers > diff --git a/mm/Kconfig b/mm/Kconfig > index 48b1af4..a342c77 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE > config MEMORY_HOTPLUG_DEFAULT_ONLINE > bool "Online the newly added memory blocks by default" > default n > - depends on MEMORY_HOTPLUG > + depends on MEMORY_HOTPLUG && !PPC64 > help > This option sets the default policy setting for memory hotplug > onlining policy (/sys/devices/system/memory/auto_online_blocks) which > -- > 2.9.4 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch 2017-08-01 9:59 ` Michael Ellerman @ 2017-08-01 14:05 ` Nathan Fontenot 2017-08-01 14:39 ` Daniel Henrique Barboza 0 siblings, 1 reply; 6+ messages in thread From: Nathan Fontenot @ 2017-08-01 14:05 UTC (permalink / raw) To: Michael Ellerman, Daniel Henrique Barboza, linuxppc-dev On 08/01/2017 04:59 AM, Michael Ellerman wrote: > Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes: > >> Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online >> hotplugged memory'") reverted the auto-online feature for pseries due >> to problems with LMB removals not updating the device struct properly. >> Among other things, this commit made the following change in >> arch/powerpc/configs/pseries_defconfig: >> >> @@ -58,7 +58,6 @@ CONFIG_KEXEC_FILE=y >> CONFIG_IRQ_ALL_CPUS=y >> CONFIG_MEMORY_HOTPLUG=y >> CONFIG_MEMORY_HOTREMOVE=y >> -CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y >> CONFIG_KSM=y >> >> The intent was to disable the option in the defconfig of pseries, since >> after that the code doesn't have this support anymore. > > It's always polite to Cc the author of a commit you're referring to, so > I added Nathan. > > The intention when we merged that fix was that the auto-online code > would be "fixed" to mark the device online. I say "fixed" because it > wasn't entirely clear if that was the correct behaviour, though it > definitely seemed like it should be. > > I've lost track of where/if the discussion got to on whether the > auto-online code should do that or not. Did anything get resolved? I think, though I should go back and test to be sure, that everything works in the latest mainline code. The issue causing this to be a problem was in the original implementation of auto_online support. If you wanted to auto online memory, the code was calling memory_block_change_state(). This worked but did not update the device struct for each of the memory block that was online'ed such that dev->offline == true even after the memory was online. I sent a patch earlier this year (commit dc18d706a436) that corrected this to call device_online() instead of memory_block_change_state(). With this fix (appears to have gone into the 4.11 kernel) it should be possible to use auto_online on power systems. At this point I don't think we need this patch to disable auto online for ppc64. I would be curious if this is still broken with the latest mainline code though. -Nathan > >> However, this change >> alone isn't enough to prevent situations such as [1], where >> distros can enable the option unaware of the consequences of >> doing it (e.g. breaking LMB hotplug altogether). >> >> Instead of relying on all distros knowing that pseries can't handle >> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch >> changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config >> unavailable for the PPC64 arch. >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380 >> >> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'") >> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> >> --- >> mm/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > I don't own that file, so we at least need an Ack from the mm folks. > > cheers > >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 48b1af4..a342c77 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE >> config MEMORY_HOTPLUG_DEFAULT_ONLINE >> bool "Online the newly added memory blocks by default" >> default n >> - depends on MEMORY_HOTPLUG >> + depends on MEMORY_HOTPLUG && !PPC64 >> help >> This option sets the default policy setting for memory hotplug >> onlining policy (/sys/devices/system/memory/auto_online_blocks) which >> -- >> 2.9.4 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch 2017-08-01 14:05 ` Nathan Fontenot @ 2017-08-01 14:39 ` Daniel Henrique Barboza 2017-08-02 10:55 ` Daniel Henrique Barboza 0 siblings, 1 reply; 6+ messages in thread From: Daniel Henrique Barboza @ 2017-08-01 14:39 UTC (permalink / raw) To: Nathan Fontenot, Michael Ellerman, linuxppc-dev On 08/01/2017 11:05 AM, Nathan Fontenot wrote: > On 08/01/2017 04:59 AM, Michael Ellerman wrote: >> Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes: >> >>> Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online >>> hotplugged memory'") reverted the auto-online feature for pseries due >>> to problems with LMB removals not updating the device struct properly. >>> Among other things, this commit made the following change in >>> arch/powerpc/configs/pseries_defconfig: >>> >>> @@ -58,7 +58,6 @@ CONFIG_KEXEC_FILE=y >>> CONFIG_IRQ_ALL_CPUS=y >>> CONFIG_MEMORY_HOTPLUG=y >>> CONFIG_MEMORY_HOTREMOVE=y >>> -CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y >>> CONFIG_KSM=y >>> >>> The intent was to disable the option in the defconfig of pseries, since >>> after that the code doesn't have this support anymore. >> It's always polite to Cc the author of a commit you're referring to, so >> I added Nathan. Noted. Thanks for adding Nathan in the CC. >> >> The intention when we merged that fix was that the auto-online code >> would be "fixed" to mark the device online. I say "fixed" because it >> wasn't entirely clear if that was the correct behaviour, though it >> definitely seemed like it should be. >> >> I've lost track of where/if the discussion got to on whether the >> auto-online code should do that or not. Did anything get resolved? > I think, though I should go back and test to be sure, that everything > works in the latest mainline code. The issue causing this to be a problem > was in the original implementation of auto_online support. If you wanted > to auto online memory, the code was calling memory_block_change_state(). > This worked but did not update the device struct for each of the memory > block that was online'ed such that dev->offline == true even after the > memory was online. > > I sent a patch earlier this year (commit dc18d706a436) that corrected > this to call device_online() instead of memory_block_change_state(). > With this fix (appears to have gone into the 4.11 kernel) it should be > possible to use auto_online on power systems. Commit dc18d706a436 was present in the 4.11 kernels that experiences this issue (Fedora 26 and Ubuntu 17.10 in my tests). So I am not entirely sure that we can use auto_online on power systems, at least in those kernels. > > At this point I don't think we need this patch to disable auto online > for ppc64. I would be curious if this is still broken with the latest > mainline code though. If the auto_online feature is already working in upstream 4.13 kernel then I don't see a reason to apply this patch either. We can leave it as a FYI/reminder of a problem that was happening in 4.11 and got solved later on. Thanks, Daniel > > -Nathan > >>> However, this change >>> alone isn't enough to prevent situations such as [1], where >>> distros can enable the option unaware of the consequences of >>> doing it (e.g. breaking LMB hotplug altogether). >>> >>> Instead of relying on all distros knowing that pseries can't handle >>> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch >>> changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config >>> unavailable for the PPC64 arch. >>> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380 >>> >>> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'") >>> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> >>> --- >>> mm/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >> I don't own that file, so we at least need an Ack from the mm folks. >> >> cheers >> >>> diff --git a/mm/Kconfig b/mm/Kconfig >>> index 48b1af4..a342c77 100644 >>> --- a/mm/Kconfig >>> +++ b/mm/Kconfig >>> @@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE >>> config MEMORY_HOTPLUG_DEFAULT_ONLINE >>> bool "Online the newly added memory blocks by default" >>> default n >>> - depends on MEMORY_HOTPLUG >>> + depends on MEMORY_HOTPLUG && !PPC64 >>> help >>> This option sets the default policy setting for memory hotplug >>> onlining policy (/sys/devices/system/memory/auto_online_blocks) which >>> -- >>> 2.9.4 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch 2017-08-01 14:39 ` Daniel Henrique Barboza @ 2017-08-02 10:55 ` Daniel Henrique Barboza 2017-08-02 14:47 ` Nathan Fontenot 0 siblings, 1 reply; 6+ messages in thread From: Daniel Henrique Barboza @ 2017-08-02 10:55 UTC (permalink / raw) To: Nathan Fontenot, Michael Ellerman, linuxppc-dev On 08/01/2017 11:39 AM, Daniel Henrique Barboza wrote: > > > On 08/01/2017 11:05 AM, Nathan Fontenot wrote: > >> >> At this point I don't think we need this patch to disable auto online >> for ppc64. I would be curious if this is still broken with the latest >> mainline code though. > > If the auto_online feature is already working in upstream 4.13 kernel > then I don't see > a reason to apply this patch either. We can leave it as a FYI/reminder > of a problem > that was happening in 4.11 and got solved later on. I've compiled an upstream kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y and the problem with LMB hotplug is still reproducible. This means that it would be good to have any sort of mechanism (such as the one this patch proposes) to remove this option from the pseries kernel until it is fixed. Here is the stack trace: Last login: Tue Aug 1 19:26:21 on hvc0 [danielhb@localhost ~]$ uname -a Linux localhost.localdomain 4.13.0-rc3+ #1 SMP Tue Aug 1 21:29:14 CDT 2017 ppc64le ppc64le ppc64le GNU/Linux [danielhb@localhost ~]$ QEMU 2.9.90 monitor - type 'help' for more information (qemu) (qemu) object_add memory-backend-ram,id=ram1,size=1G (qemu) device_add pc-dimm,id=dimm1,memdev=ram1 (qemu) [ 617.757086] kernel BUG at mm/memory_hotplug.c:1936! [ 617.757245] Oops: Exception in kernel mode, sig: 5 [#1] [ 617.757332] SMP NR_CPUS=1024 [ 617.757333] NUMA [ 617.757396] pSeries [ 617.757479] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc ghash_generic vmx_crypto xfs libcrc32c bochs_drm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_blk ibmvscsi virtio_pci ibmveth scsi_transport_srp i2c_core virtio_ring virtio crc32c_vpmsum [ 617.758577] CPU: 6 PID: 5 Comm: kworker/u16:0 Not tainted 4.13.0-rc3+ #1 [ 617.758741] Workqueue: pseries hotplug workque pseries_hp_work_fn [ 617.758852] task: c0000000feb9e780 task.stack: c0000000fe118000 [ 617.759047] NIP: c00000000037322c LR: c0000000003731b8 CTR: 0000000000000000 [ 617.759171] REGS: c0000000fe11b790 TRAP: 0700 Not tainted (4.13.0-rc3+) [ 617.759275] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> [ 617.759284] CR: 22002424 XER: 20000000 [ 617.759450] CFAR: c0000000003731bc SOFTE: 1 [ 617.759450] GPR00: c0000000003731b8 c0000000fe11ba10 c00000000141f100 0000000000000001 [ 617.759450] GPR04: 0000000000000000 00000000000001a0 c0000000015dac30 0000000000008b80 [ 617.759450] GPR08: 0000000000000007 0000000000000002 c0000000e9873480 303078302d303030 [ 617.759450] GPR12: 0000000000002200 c00000000fd83c00 c000000000137f88 c0000000fe1f0e40 [ 617.759450] GPR16: 0000000000000000 0000000000000001 0000000000000004 0000000000000001 [ 617.759450] GPR20: c0000000fffffc28 0000000000000010 c0000000ebb1c184 0000000000000010 [ 617.759450] GPR24: c0000000fffffea0 c0000000f0aec4a0 c0000000fffffc28 0000000000000000 [ 617.759450] GPR28: 0000000000000000 c000000001347f08 0000000010000000 0000000100000000 [ 617.760679] NIP [c00000000037322c] remove_memory+0xfc/0x110 [ 617.760766] LR [c0000000003731b8] remove_memory+0x88/0x110 [ 617.760849] Call Trace: [ 617.760895] [c0000000fe11ba10] [c0000000003731b8] remove_memory+0x88/0x110 (unreliable) [ 617.761032] [c0000000fe11ba50] [c0000000000cb0e0] dlpar_add_lmb+0x280/0x480 [ 617.761214] [c0000000fe11bb30] [c0000000000cc83c] dlpar_memory+0xa5c/0xe50 [ 617.761319] [c0000000fe11bbf0] [c0000000000c3b88] handle_dlpar_errorlog+0xf8/0x160 [ 617.761443] [c0000000fe11bc60] [c0000000000c3c84] pseries_hp_work_fn+0x94/0xa0 [ 617.761568] [c0000000fe11bc90] [c00000000012e3e8] process_one_work+0x248/0x540 [ 617.761697] [c0000000fe11bd30] [c00000000012e768] worker_thread+0x88/0x5c0 [ 617.761857] [c0000000fe11bdc0] [c00000000013812c] kthread+0x1ac/0x1c0 [ 617.761962] [c0000000fe11be30] [c00000000000bc9c] ret_from_kernel_thread+0x5c/0xc0 [ 617.762085] Instruction dump: [ 617.762149] 4be09a9d 60000000 4bd95ac5 60000000 38210040 e8010010 eb81ffe0 eba1ffe8 [ 617.762274] ebc1fff0 7c0803a6 ebe1fff8 4e800020 <0fe00000> 00000000 00000000 00000000 [ 617.762403] ---[ end trace feaa62099c5987b9 ]--- Thanks, Daniel > > > Thanks, > > > Daniel > >> >> -Nathan >>>> However, this change >>>> alone isn't enough to prevent situations such as [1], where >>>> distros can enable the option unaware of the consequences of >>>> doing it (e.g. breaking LMB hotplug altogether). >>>> >>>> Instead of relying on all distros knowing that pseries can't handle >>>> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch >>>> changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config >>>> unavailable for the PPC64 arch. >>>> >>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380 >>>> >>>> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online >>>> hotplugged memory'") >>>> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> >>>> --- >>>> mm/Kconfig | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> I don't own that file, so we at least need an Ack from the mm folks. >>> >>> cheers >>> >>>> diff --git a/mm/Kconfig b/mm/Kconfig >>>> index 48b1af4..a342c77 100644 >>>> --- a/mm/Kconfig >>>> +++ b/mm/Kconfig >>>> @@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE >>>> config MEMORY_HOTPLUG_DEFAULT_ONLINE >>>> bool "Online the newly added memory blocks by default" >>>> default n >>>> - depends on MEMORY_HOTPLUG >>>> + depends on MEMORY_HOTPLUG && !PPC64 >>>> help >>>> This option sets the default policy setting for memory hotplug >>>> onlining policy >>>> (/sys/devices/system/memory/auto_online_blocks) which >>>> -- >>>> 2.9.4 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch 2017-08-02 10:55 ` Daniel Henrique Barboza @ 2017-08-02 14:47 ` Nathan Fontenot 0 siblings, 0 replies; 6+ messages in thread From: Nathan Fontenot @ 2017-08-02 14:47 UTC (permalink / raw) To: Daniel Henrique Barboza, Michael Ellerman, linuxppc-dev On 08/02/2017 05:55 AM, Daniel Henrique Barboza wrote: > > On 08/01/2017 11:39 AM, Daniel Henrique Barboza wrote: >> >> On 08/01/2017 11:05 AM, Nathan Fontenot wrote: >> >>> At this point I don't think we need this patch to disable auto online >>> for ppc64. I would be curious if this is still broken with the latest >>> mainline code though. >> >> If the auto_online feature is already working in upstream 4.13 kernel then I don't see >> a reason to apply this patch either. We can leave it as a FYI/reminder of a problem >> that was happening in 4.11 and got solved later on. > > I've compiled an upstream kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y > and the problem with LMB hotplug is still reproducible. Yes, I was able to re-create the same failure. > > This means that it would be good to have any sort of mechanism (such as the one this > patch proposes) to remove this option from the pseries kernel until it is fixed. After looking through the pseries dlpar code I found the issue. The dlpar code assumes the memory is offline after adding it. The call to device_online() then returns non-zero (because the memory is already online) and the dlpar code interprets that as a failure and tries to remove the memory. This then causes the oops we see below because the memory is not offlined prior to the remove call. There is a similar issue with memory remove when the memory is offlined (via sysfs) prior to trying to dlpar remove the memory. The attempt to dlpar remove fails, luckily with just an error message and not an oops. I'll send a patch out to fix this. -Nathan > > Here is the stack trace: > > > Last login: Tue Aug 1 19:26:21 on hvc0 > [danielhb@localhost ~]$ uname -a > Linux localhost.localdomain 4.13.0-rc3+ #1 SMP Tue Aug 1 21:29:14 CDT 2017 ppc64le ppc64le ppc64le GNU/Linux > [danielhb@localhost ~]$ QEMU 2.9.90 monitor - type 'help' for more information > (qemu) > (qemu) object_add memory-backend-ram,id=ram1,size=1G > (qemu) device_add pc-dimm,id=dimm1,memdev=ram1 > (qemu) [ 617.757086] kernel BUG at mm/memory_hotplug.c:1936! > [ 617.757245] Oops: Exception in kernel mode, sig: 5 [#1] > [ 617.757332] SMP NR_CPUS=1024 > [ 617.757333] NUMA > [ 617.757396] pSeries > [ 617.757479] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc ghash_generic vmx_crypto xfs libcrc32c bochs_drm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_blk ibmvscsi virtio_pci ibmveth scsi_transport_srp i2c_core virtio_ring virtio crc32c_vpmsum > [ 617.758577] CPU: 6 PID: 5 Comm: kworker/u16:0 Not tainted 4.13.0-rc3+ #1 > [ 617.758741] Workqueue: pseries hotplug workque pseries_hp_work_fn > [ 617.758852] task: c0000000feb9e780 task.stack: c0000000fe118000 > [ 617.759047] NIP: c00000000037322c LR: c0000000003731b8 CTR: 0000000000000000 > [ 617.759171] REGS: c0000000fe11b790 TRAP: 0700 Not tainted (4.13.0-rc3+) > [ 617.759275] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> > [ 617.759284] CR: 22002424 XER: 20000000 > [ 617.759450] CFAR: c0000000003731bc SOFTE: 1 > [ 617.759450] GPR00: c0000000003731b8 c0000000fe11ba10 c00000000141f100 0000000000000001 > [ 617.759450] GPR04: 0000000000000000 00000000000001a0 c0000000015dac30 0000000000008b80 > [ 617.759450] GPR08: 0000000000000007 0000000000000002 c0000000e9873480 303078302d303030 > [ 617.759450] GPR12: 0000000000002200 c00000000fd83c00 c000000000137f88 c0000000fe1f0e40 > [ 617.759450] GPR16: 0000000000000000 0000000000000001 0000000000000004 0000000000000001 > [ 617.759450] GPR20: c0000000fffffc28 0000000000000010 c0000000ebb1c184 0000000000000010 > [ 617.759450] GPR24: c0000000fffffea0 c0000000f0aec4a0 c0000000fffffc28 0000000000000000 > [ 617.759450] GPR28: 0000000000000000 c000000001347f08 0000000010000000 0000000100000000 > [ 617.760679] NIP [c00000000037322c] remove_memory+0xfc/0x110 > [ 617.760766] LR [c0000000003731b8] remove_memory+0x88/0x110 > [ 617.760849] Call Trace: > [ 617.760895] [c0000000fe11ba10] [c0000000003731b8] remove_memory+0x88/0x110 (unreliable) > [ 617.761032] [c0000000fe11ba50] [c0000000000cb0e0] dlpar_add_lmb+0x280/0x480 > [ 617.761214] [c0000000fe11bb30] [c0000000000cc83c] dlpar_memory+0xa5c/0xe50 > [ 617.761319] [c0000000fe11bbf0] [c0000000000c3b88] handle_dlpar_errorlog+0xf8/0x160 > [ 617.761443] [c0000000fe11bc60] [c0000000000c3c84] pseries_hp_work_fn+0x94/0xa0 > [ 617.761568] [c0000000fe11bc90] [c00000000012e3e8] process_one_work+0x248/0x540 > [ 617.761697] [c0000000fe11bd30] [c00000000012e768] worker_thread+0x88/0x5c0 > [ 617.761857] [c0000000fe11bdc0] [c00000000013812c] kthread+0x1ac/0x1c0 > [ 617.761962] [c0000000fe11be30] [c00000000000bc9c] ret_from_kernel_thread+0x5c/0xc0 > [ 617.762085] Instruction dump: > [ 617.762149] 4be09a9d 60000000 4bd95ac5 60000000 38210040 e8010010 eb81ffe0 eba1ffe8 > [ 617.762274] ebc1fff0 7c0803a6 ebe1fff8 4e800020 <0fe00000> 00000000 00000000 00000000 > [ 617.762403] ---[ end trace feaa62099c5987b9 ]--- > > > Thanks, > > > Daniel > >> >> >> Thanks, >> >> >> Daniel >> >>> >>> -Nathan >>>>> However, this change >>>>> alone isn't enough to prevent situations such as [1], where >>>>> distros can enable the option unaware of the consequences of >>>>> doing it (e.g. breaking LMB hotplug altogether). >>>>> >>>>> Instead of relying on all distros knowing that pseries can't handle >>>>> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y after 943db62c316c, this patch >>>>> changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config >>>>> unavailable for the PPC64 arch. >>>>> >>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380 >>>>> >>>>> Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'") >>>>> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> >>>>> --- >>>>> mm/Kconfig | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> I don't own that file, so we at least need an Ack from the mm folks. >>>> >>>> cheers >>>> >>>>> diff --git a/mm/Kconfig b/mm/Kconfig >>>>> index 48b1af4..a342c77 100644 >>>>> --- a/mm/Kconfig >>>>> +++ b/mm/Kconfig >>>>> @@ -169,7 +169,7 @@ config MEMORY_HOTPLUG_SPARSE >>>>> config MEMORY_HOTPLUG_DEFAULT_ONLINE >>>>> bool "Online the newly added memory blocks by default" >>>>> default n >>>>> - depends on MEMORY_HOTPLUG >>>>> + depends on MEMORY_HOTPLUG && !PPC64 >>>>> help >>>>> This option sets the default policy setting for memory hotplug >>>>> onlining policy (/sys/devices/system/memory/auto_online_blocks) which >>>>> -- >>>>> 2.9.4 >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-08-02 14:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-07-31 18:17 [RFC PATCH] powerpc: Disabling MEMORY_HOTPLUG_DEFAULT_ONLINE option for PPC64 arch Daniel Henrique Barboza 2017-08-01 9:59 ` Michael Ellerman 2017-08-01 14:05 ` Nathan Fontenot 2017-08-01 14:39 ` Daniel Henrique Barboza 2017-08-02 10:55 ` Daniel Henrique Barboza 2017-08-02 14:47 ` Nathan Fontenot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).