* [PATCH AUTOSEL 5.1 89/95] powerpc: enable a 30-bit ZONE_DMA for 32-bit pmac
From: Sasha Levin @ 2019-06-27 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Aaro Koskinen, linuxppc-dev, Christoph Hellwig,
Larry Finger
In-Reply-To: <20190627003021.19867-1-sashal@kernel.org>
From: Christoph Hellwig <hch@lst.de>
[ Upstream commit 9739ab7eda459f0669ec9807e0d9be5020bab88c ]
With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit powerbooks
stopped working. Add a 30-bit ZONE_DMA to the 32-bit pmac builds
to allow them to reliably allocate dma coherent memory.
Fixes: 65a21b71f948 ("powerpc/dma: remove dma_nommu_dma_supported")
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/page.h | 7 +++++++
arch/powerpc/mm/mem.c | 3 ++-
arch/powerpc/platforms/powermac/Kconfig | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index ed870468ef6f..d408711d09fb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -330,6 +330,13 @@ struct vm_area_struct;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>
+/*
+ * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
+ */
+#ifdef CONFIG_PPC32
+#define ARCH_ZONE_DMA_BITS 30
+#else
#define ARCH_ZONE_DMA_BITS 31
+#endif
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f6787f90e158..b98ce400a889 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -255,7 +255,8 @@ void __init paging_init(void)
(long int)((top_of_ram - total_ram) >> 20));
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
+ ((1UL << ARCH_ZONE_DMA_BITS) - 1) >> PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig
index f834a19ed772..c02d8c503b29 100644
--- a/arch/powerpc/platforms/powermac/Kconfig
+++ b/arch/powerpc/platforms/powermac/Kconfig
@@ -7,6 +7,7 @@ config PPC_PMAC
select PPC_INDIRECT_PCI if PPC32
select PPC_MPC106 if PPC32
select PPC_NATIVE
+ select ZONE_DMA if PPC32
default y
config PPC_PMAC64
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 26/60] ibmvnic: Do not close unopened driver during reset
From: Sasha Levin @ 2019-06-27 0:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, Thomas Falcon, linuxppc-dev,
David S . Miller
In-Reply-To: <20190627003616.20767-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit 1f94608b0ce141be5286dde31270590bdf35b86a ]
Check driver state before halting it during a reset. If the driver is
not running, do nothing. Otherwise, a request to deactivate a down link
can cause an error and the reset will fail.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 426789e2c23d..bf0a5fe0da17 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1754,7 +1754,8 @@ static int do_reset(struct ibmvnic_adapter *adapter,
ibmvnic_cleanup(netdev);
- if (adapter->reset_reason != VNIC_RESET_MOBILITY &&
+ if (reset_state == VNIC_OPEN &&
+ adapter->reset_reason != VNIC_RESET_MOBILITY &&
adapter->reset_reason != VNIC_RESET_FAILOVER) {
rc = __ibmvnic_close(netdev);
if (rc)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 27/60] ibmvnic: Refresh device multicast list after reset
From: Sasha Levin @ 2019-06-27 0:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, Thomas Falcon, linuxppc-dev,
David S . Miller
In-Reply-To: <20190627003616.20767-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit be32a24372cf162e825332da1a7ccef058d4f20b ]
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index bf0a5fe0da17..b88af81499e8 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1854,6 +1854,9 @@ static int do_reset(struct ibmvnic_adapter *adapter,
return 0;
}
+ /* refresh device's multicast list */
+ ibmvnic_set_multi(netdev);
+
/* kick napi */
for (i = 0; i < adapter->req_rx_queues; i++)
napi_schedule(&adapter->napi[i]);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 28/60] ibmvnic: Fix unchecked return codes of memory allocations
From: Sasha Levin @ 2019-06-27 0:35 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, Thomas Falcon, linuxppc-dev,
David S . Miller
In-Reply-To: <20190627003616.20767-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit 7c940b1a5291e5069d561f5b8f0e51db6b7a259a ]
The return values for these memory allocations are unchecked,
which may cause an oops if the driver does not handle them after
a failure. Fix by checking the function's return code.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index b88af81499e8..0ae43d27cdcf 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -438,9 +438,10 @@ static int reset_rx_pools(struct ibmvnic_adapter *adapter)
if (rx_pool->buff_size != be64_to_cpu(size_array[i])) {
free_long_term_buff(adapter, &rx_pool->long_term_buff);
rx_pool->buff_size = be64_to_cpu(size_array[i]);
- alloc_long_term_buff(adapter, &rx_pool->long_term_buff,
- rx_pool->size *
- rx_pool->buff_size);
+ rc = alloc_long_term_buff(adapter,
+ &rx_pool->long_term_buff,
+ rx_pool->size *
+ rx_pool->buff_size);
} else {
rc = reset_long_term_buff(adapter,
&rx_pool->long_term_buff);
@@ -706,9 +707,9 @@ static int init_tx_pools(struct net_device *netdev)
return rc;
}
- init_one_tx_pool(netdev, &adapter->tso_pool[i],
- IBMVNIC_TSO_BUFS,
- IBMVNIC_TSO_BUF_SZ);
+ rc = init_one_tx_pool(netdev, &adapter->tso_pool[i],
+ IBMVNIC_TSO_BUFS,
+ IBMVNIC_TSO_BUF_SZ);
if (rc) {
release_tx_pools(adapter);
return rc;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 17/35] ibmvnic: Refresh device multicast list after reset
From: Sasha Levin @ 2019-06-27 0:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, netdev, Thomas Falcon, linuxppc-dev,
David S . Miller
In-Reply-To: <20190627003925.21330-1-sashal@kernel.org>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
[ Upstream commit be32a24372cf162e825332da1a7ccef058d4f20b ]
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index c914b338691b..956fbb164e6f 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1489,6 +1489,9 @@ static int do_reset(struct ibmvnic_adapter *adapter,
return 0;
}
+ /* refresh device's multicast list */
+ ibmvnic_set_multi(netdev);
+
/* kick napi */
for (i = 0; i < adapter->req_rx_queues; i++)
napi_schedule(&adapter->napi[i]);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] powerpc/pseries: Update SCM hcall op-codes in hvcall.h
From: Oliver O'Halloran @ 2019-06-27 1:10 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Laurent Dufour, Vaibhav Jain, David Gibson, linuxppc-dev
In-Reply-To: <87mui4z3t2.fsf@linux.ibm.com>
On Thu, Jun 27, 2019 at 2:53 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>
> > Update the hvcalls.h to include op-codes for new hcalls introduce to
> > manage SCM memory. Also update existing hcall definitions to reflect
> > current papr specification for SCM.
> >
> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
>
>
> Why split this as a separate patch? You should fold this to the next one
> where we actually use the constant.
I figured if you're going to update the hcall numbers to reflect
reality then it should be done in a separate patch. Single logical
change per patch and all that.
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails
From: Oliver O'Halloran @ 2019-06-27 1:41 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Laurent Dufour, Vaibhav Jain, David Gibson, linuxppc-dev
In-Reply-To: <87k1d8z3jw.fsf@linux.ibm.com>
On Thu, Jun 27, 2019 at 2:58 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> > *snip*
> > + /* If phyp says drc memory still bound then force unbound and retry */
> > + if (rc == -EBUSY) {
> > + dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
> > + drc_pmem_unbind(p);
> This should only be caused by kexec right?
We should only ever hit this path if there's an unclean shutdown, so
kdump or fadump. For a normal kexec the previous kernel should have
torn down the binding for us.
> And considering kernel nor
> hypervisor won't change device binding details, can you check switching
> this to H_SCM_QUERY_BLOCK_MEM_BINDING?
I thought about using the QUERY_BLOCK_MEM_BINDING call, but I'm not
sure it's a good idea. It bakes in assumptions about what the
*previous* kernel did with the SCM volume that might not be valid. A
panic while unbinding a region would result in a partially-bound
region which might break the query call. Also, it's possible that we
might have SCM drivers in the future that do something other than just
binding the volume in one contiguous chunk. UNBIND_ALL is robust
against all of these and robustness is what you want out of an error
handling mechanism.
> Will that result in faster boot?
As I said in the comments on v1, do we have any actual numbers on how
long the bind step takes? From memory, you could bind ~32GB in a
single bind h-call before phyp would hit it's time limit of 250us and
return a continue token. Assuming that holds we'll be saving a few
dozen milliseconds at best.
> > + rc = drc_pmem_bind(p);
> > + }
> > +
> > if (rc)
> > goto err;
> >
>
> I am also not sure about the module reference count here. Should we
> increment the module reference count after a bind so that we can track
> failures in ubind and fail the module unload?
I don't really get what you're concerned about here. The error
handling path calls drc_pmem_unbind() so if there's a bind error we
should never leave probe with memory still bound.
> -aneesh
>
^ permalink raw reply
* RE: [EXT] Re: [PATCHv2 2/2] PCI: layerscape: EP and RC drivers are compiled separately
From: Xiaowei Bao @ 2019-06-27 2:00 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, kstewart@linuxfoundation.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
pombredanne@nexb.com, Leo Li, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190626175153.GC103694@google.com>
Hi Bjorn,
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: 2019年6月27日 1:52
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com;
> arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian
> <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang
> <roy.zang@nxp.com>; kstewart@linuxfoundation.org;
> pombredanne@nexb.com; shawn.lin@rock-chips.com;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: [EXT] Re: [PATCHv2 2/2] PCI: layerscape: EP and RC drivers are
> compiled separately
>
> Caution: EXT Email
>
> If you post another revision for any reason, please change the subject so it's
> worded as a command and mentions the new config options, e.g.,
>
> PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC
> separately
[Xiaowei Bao] OK, thanks, this subject looks well.
>
> On Wed, Jun 26, 2019 at 07:11:39PM +0800, Xiaowei Bao wrote:
> > Compile the EP and RC drivers separately with different configuration
> > options, this looks clearer.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> >
> > drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
> > drivers/pci/controller/dwc/Makefile | 3 ++-
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/Kconfig
> > b/drivers/pci/controller/dwc/Kconfig
> > index a6ce1ee..a41ccf5 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
> > DesignWare core functions to implement the driver.
> >
> > config PCI_LAYERSCAPE
> > - bool "Freescale Layerscape PCIe controller"
> > + bool "Freescale Layerscape PCIe controller - Host mode"
> > depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> > depends on PCI_MSI_IRQ_DOMAIN
> > select MFD_SYSCON
> > select PCIE_DW_HOST
> > help
> > - Say Y here if you want PCIe controller support on Layerscape SoCs.
> > + Say Y here if you want to enable PCIe controller support on
> Layerscape
> > + SoCs to work in Host mode.
> > + This controller can work either as EP or RC. The
> RCW[HOST_AGT_PEX]
> > + determines which PCIe controller works in EP mode and which
> PCIe
> > + controller works in RC mode.
> > +
> > +config PCI_LAYERSCAPE_EP
> > + bool "Freescale Layerscape PCIe controller - Endpoint mode"
> > + depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> > + depends on PCI_ENDPOINT
> > + select PCIE_DW_EP
> > + help
> > + Say Y here if you want to enable PCIe controller support on
> Layerscape
> > + SoCs to work in Endpoint mode.
> > + This controller can work either as EP or RC. The
> RCW[HOST_AGT_PEX]
> > + determines which PCIe controller works in EP mode and which
> PCIe
> > + controller works in RC mode.
> >
> > config PCI_HISI
> > depends on OF && (ARM64 || COMPILE_TEST) diff --git
> > a/drivers/pci/controller/dwc/Makefile
> > b/drivers/pci/controller/dwc/Makefile
> > index b085dfd..824fde7 100644
> > --- a/drivers/pci/controller/dwc/Makefile
> > +++ b/drivers/pci/controller/dwc/Makefile
> > @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> > obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> > obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> > obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
> > -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
> > +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> > +obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
> > obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> > obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> > obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> > --
> > 1.7.1
> >
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails
From: Aneesh Kumar K.V @ 2019-06-27 2:56 UTC (permalink / raw)
To: Oliver O'Halloran
Cc: Laurent Dufour, Vaibhav Jain, David Gibson, linuxppc-dev
In-Reply-To: <CAOSf1CEPZcq-hkJCxRnb7nZ8Smib6uDm6J_Lp6ec5sP7+DQDEQ@mail.gmail.com>
"Oliver O'Halloran" <oohall@gmail.com> writes:
> As I said in the comments on v1, do we have any actual numbers on how
> long the bind step takes? From memory, you could bind ~32GB in a
> single bind h-call before phyp would hit it's time limit of 250us and
> return a continue token. Assuming that holds we'll be saving a few
> dozen milliseconds at best.
>
>> > + rc = drc_pmem_bind(p);
>> > + }
>> > +
>> > if (rc)
>> > goto err;
>> >
>>
>> I am also not sure about the module reference count here. Should we
>> increment the module reference count after a bind so that we can track
>> failures in ubind and fail the module unload?
>
> I don't really get what you're concerned about here. The error
> handling path calls drc_pmem_unbind() so if there's a bind error we
> should never leave probe with memory still bound.
>
In the remove callback, if the ubind fail should we allow the module
unload?
-aneesh
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails
From: Oliver O'Halloran @ 2019-06-27 3:39 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Laurent Dufour, Vaibhav Jain, David Gibson, linuxppc-dev
In-Reply-To: <87h88bzqfd.fsf@linux.ibm.com>
On Thu, Jun 27, 2019 at 12:58 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> "Oliver O'Halloran" <oohall@gmail.com> writes:
>
> >> > + rc = drc_pmem_bind(p);
> >> > + }
> >> > +
> >> > if (rc)
> >> > goto err;
> >> >
> >>
> >> I am also not sure about the module reference count here. Should we
> >> increment the module reference count after a bind so that we can track
> >> failures in ubind and fail the module unload?
> >
> > I don't really get what you're concerned about here. The error
> > handling path calls drc_pmem_unbind() so if there's a bind error we
> > should never leave probe with memory still bound.
> >
>
> In the remove callback, if the ubind fail should we allow the module
> unload?
If the drc_pmem_unbind() in the driver's remove function fails the
driver will still be unbound from the platform device for that DRC.
You can try re-bind the driver to the platform device and it'll hit
the unbind-then-bind again error path this series introduces (which
might also fail), but that's fine. The only reasons I can think of for
drc_pmem_unbind() failing are bugs in the hypervisor or bugs in the
driver. Forcing the module to stay loaded doesn't help either case so
I'm not seeing the benefit.
Oliver
^ permalink raw reply
* Re: [PATCH v1] powerpc: Fix BUG_ON during memory unplug on radix
From: Aneesh Kumar K.V @ 2019-06-27 3:57 UTC (permalink / raw)
To: Bharata B Rao, linuxppc-dev
Cc: sraithal, aneesh.kumar, npiggin, Bharata B Rao
In-Reply-To: <20190624060343.4940-1-bharata@linux.ibm.com>
Bharata B Rao <bharata@linux.ibm.com> writes:
> We hit the following BUG_ON when memory hotplugged before reboot
> is unplugged after reboot:
>
> kernel BUG at arch/powerpc/mm/pgtable-frag.c:113!
>
> remove_pagetable+0x594/0x6a0
> (unreliable)
> remove_pagetable+0x94/0x6a0
> vmemmap_free+0x394/0x410
> sparse_remove_one_section+0x26c/0x2e8
> __remove_pages+0x428/0x540
> arch_remove_memory+0xd0/0x170
> __remove_memory+0xd4/0x1a0
> dlpar_remove_lmb+0xbc/0x110
> dlpar_memory+0xa80/0xd20
> handle_dlpar_errorlog+0xa8/0x160
> pseries_hp_work_fn+0x2c/0x60
> process_one_work+0x46c/0x860
> worker_thread+0x364/0x5e0
> kthread+0x1b0/0x1c0
> ret_from_kernel_thread+0x5c/0x68
>
> This occurs because, during reboot-after-hotplug, the hotplugged
> memory range gets initialized as regular memory and page
> tables are setup using memblock allocator. This means that we
> wouldn't have initialized the PMD or PTE fragment count for
> those PMD or PTE pages.
>
> Fixing this includes 3 parts:
>
> - Re-walk the init_mm page tables from mem_init() and initialize
> the PMD and PTE fragment counts appropriately. So PMD and PTE
> table pages allocated during early allocation will have a
> fragment count of 1.
> - Convert the pages from memblock pages to regular pages so that
> they can be freed back to buddy allocator seamlessly. However
> we do this for only PMD and PTE pages and not for PUD pages.
> PUD pages are freed using kmem_cache_free() and we need to
> identify memblock pages and free them differently.
> - When we do early memblock based allocation of PMD and PUD pages,
> allocate in PAGE_SIZE granularity so that we are sure the
> complete page is used as pagetable page. PAGE_SIZE allocations will
> have an implication on the amount of memory used for page tables,
> an example of which is shown below:
>
> Since we now do PAGE_SIZE allocations for both PUD table and
> PMD table (Note that PTE table allocation is already of PAGE_SIZE),
> we end up allocating more memory for the same amount of system RAM.
> Here is an example of how much more we end up allocating for
> page tables in case of 64T system RAM:
>
> 1. Mapping system RAM
>
> With each PGD entry spanning 512G, 64TB RAM would need 128 entries
> and hence 128 PUD tables. We use 1G mapping at PUD level (level 2)
>
> With default PUD_TABLE_SIZE(4K), 128*4K=512K (8 64K pages)
> With PAGE_SIZE(64K) allocations, 128*64K=8192K (128 64K pages)
>
> 2. Mapping struct pages (memmap)
>
> 64T RAM would need 64G for memmap with struct page size being 64B.
> Since memmap array is mapped using 64K mappings, we would need
> 64 PUD entries or 64 PMD tables (level 3) in total.
>
> With default PMD_TABLE_SIZE(4K), 64*4K=256K (4 64K pages)
> With PAGE_SIZE(64K) allocations, 64*64K=4096K (64 64K pages)
>
> There is no change in PTE table (level 4) allocation requirement as
> early page table allocation is already using PAGE_SIZE PTE tables.
>
> So essentially with this change we would use 180 64K pages
> more for 64T system.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Reported-by: Srikanth Aithal <sraithal@linux.vnet.ibm.com>
> Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
> ---
> v0 - https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-June/192242.html
> Changes in v1:
> - Handling PUD table freeing too.
> - Added details about how much extra memory we use up with
> this approach into the commit message
> - A few cleanups and renames
>
> arch/powerpc/include/asm/book3s/64/pgalloc.h | 7 +-
> arch/powerpc/include/asm/book3s/64/radix.h | 1 +
> arch/powerpc/include/asm/sparsemem.h | 1 +
> arch/powerpc/mm/book3s64/pgtable.c | 15 +++-
> arch/powerpc/mm/book3s64/radix_pgtable.c | 79 +++++++++++++++++++-
> arch/powerpc/mm/mem.c | 5 ++
> 6 files changed, 104 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
> index d5a44912902f..9ae134f260be 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
> @@ -111,7 +111,12 @@ static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
>
> static inline void pud_free(struct mm_struct *mm, pud_t *pud)
> {
> - kmem_cache_free(PGT_CACHE(PUD_CACHE_INDEX), pud);
> + struct page *page = virt_to_page(pud);
> +
> + if (PageReserved(page))
> + free_reserved_page(page);
> + else
> + kmem_cache_free(PGT_CACHE(PUD_CACHE_INDEX), pud);
> }
>
> static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
> diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
> index 574eca33f893..4320f2790e8d 100644
> --- a/arch/powerpc/include/asm/book3s/64/radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/radix.h
> @@ -285,6 +285,7 @@ static inline unsigned long radix__get_tree_size(void)
> #ifdef CONFIG_MEMORY_HOTPLUG
> int radix__create_section_mapping(unsigned long start, unsigned long end, int nid);
> int radix__remove_section_mapping(unsigned long start, unsigned long end);
> +void radix__fixup_pgtable_fragments(void);
> #endif /* CONFIG_MEMORY_HOTPLUG */
> #endif /* __ASSEMBLY__ */
> #endif
> diff --git a/arch/powerpc/include/asm/sparsemem.h b/arch/powerpc/include/asm/sparsemem.h
> index 3192d454a733..e662f9232d35 100644
> --- a/arch/powerpc/include/asm/sparsemem.h
> +++ b/arch/powerpc/include/asm/sparsemem.h
> @@ -15,6 +15,7 @@
> #ifdef CONFIG_MEMORY_HOTPLUG
> extern int create_section_mapping(unsigned long start, unsigned long end, int nid);
> extern int remove_section_mapping(unsigned long start, unsigned long end);
> +void fixup_pgtable_fragments(void);
>
> #ifdef CONFIG_PPC_BOOK3S_64
> extern int resize_hpt_for_hotplug(unsigned long new_mem_size);
> diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> index 01bc9663360d..c8fa94802620 100644
> --- a/arch/powerpc/mm/book3s64/pgtable.c
> +++ b/arch/powerpc/mm/book3s64/pgtable.c
> @@ -186,6 +186,13 @@ int __meminit remove_section_mapping(unsigned long start, unsigned long end)
>
> return hash__remove_section_mapping(start, end);
> }
> +
> +void fixup_pgtable_fragments(void)
> +{
> + if (radix_enabled())
> + radix__fixup_pgtable_fragments();
> +}
> +
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> void __init mmu_partition_table_init(void)
> @@ -326,6 +333,8 @@ void pmd_fragment_free(unsigned long *pmd)
>
> static inline void pgtable_free(void *table, int index)
> {
> + struct page *page;
> +
> switch (index) {
> case PTE_INDEX:
> pte_fragment_free(table, 0);
> @@ -334,7 +343,11 @@ static inline void pgtable_free(void *table, int index)
> pmd_fragment_free(table);
> break;
> case PUD_INDEX:
> - kmem_cache_free(PGT_CACHE(PUD_CACHE_INDEX), table);
> + page = virt_to_page(table);
> + if (PageReserved(page))
> + free_reserved_page(page);
> + else
> + kmem_cache_free(PGT_CACHE(PUD_CACHE_INDEX), table);
> break;
> #if defined(CONFIG_PPC_4K_PAGES) && defined(CONFIG_HUGETLB_PAGE)
> /* 16M hugepd directory at pud level */
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 273ae66a9a45..4167e1ba1c58 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -32,6 +32,81 @@
> unsigned int mmu_pid_bits;
> unsigned int mmu_base_pid;
>
> +/*
> + * Since we know that this page is a memblock-allocated page,
> + * convert it into a normal page in addition to fixing the fragment
> + * count.
> + */
> +static void fix_fragment_count(struct page *page)
> +{
> + ClearPageReserved(page);
> + init_page_count(page);
> + adjust_managed_page_count(page, 1);
> + atomic_inc(&page->pt_frag_refcount);
> +}
> +
> +static void fixup_pte_fragments(pmd_t *pmd)
> +{
> + int i;
> +
> + for (i = 0; i < PTRS_PER_PMD; i++, pmd++) {
> + pte_t *pte;
> +
> + if (pmd_none(*pmd))
> + continue;
> + if (pmd_huge(*pmd))
> + continue;
> +
> + pte = pte_offset_kernel(pmd, 0);
> + if (!pte_none(*pte))
> + fix_fragment_count(virt_to_page(pte));
> + }
> +}
> +
> +static void fixup_pmd_fragments(pud_t *pud)
> +{
> + int i;
> +
> + for (i = 0; i < PTRS_PER_PUD; i++, pud++) {
> + pmd_t *pmd;
> +
> + if (pud_none(*pud))
> + continue;
> + if (pud_huge(*pud))
> + continue;
> +
> + pmd = pmd_offset(pud, 0);
> + if (!pmd_none(*pmd))
> + fix_fragment_count(virt_to_page(pmd));
> + fixup_pte_fragments(pmd);
> + }
> +}
> +
> +/*
> + * Walk the init_mm page tables and fixup the PMD and PTE fragment
> + * counts. This allows the PUD, PMD and PTE pages to be freed
> + * back to buddy allocator properly during memory unplug.
> + */
> +void radix__fixup_pgtable_fragments(void)
> +{
> + int i;
> + pgd_t *pgd = pgd_offset_k(0UL);
> +
> + spin_lock(&init_mm.page_table_lock);
> + for (i = 0; i < PTRS_PER_PGD; i++, pgd++) {
> + pud_t *pud;
> +
> + if (pgd_none(*pgd))
> + continue;
> + if (pgd_huge(*pgd))
> + continue;
> +
> + pud = pud_offset(pgd, 0);
> + fixup_pmd_fragments(pud);
> + }
> + spin_unlock(&init_mm.page_table_lock);
> +}
> +
> static int native_register_process_table(unsigned long base, unsigned long pg_sz,
> unsigned long table_size)
> {
> @@ -80,7 +155,7 @@ static int early_map_kernel_page(unsigned long ea, unsigned long pa,
>
> pgdp = pgd_offset_k(ea);
> if (pgd_none(*pgdp)) {
> - pudp = early_alloc_pgtable(PUD_TABLE_SIZE, nid,
> + pudp = early_alloc_pgtable(PAGE_SIZE, nid,
> region_start, region_end);
> pgd_populate(&init_mm, pgdp, pudp);
> }
> @@ -90,7 +165,7 @@ static int early_map_kernel_page(unsigned long ea, unsigned long pa,
> goto set_the_pte;
> }
> if (pud_none(*pudp)) {
> - pmdp = early_alloc_pgtable(PMD_TABLE_SIZE, nid,
> + pmdp = early_alloc_pgtable(PAGE_SIZE, nid,
> region_start, region_end);
> pud_populate(&init_mm, pudp, pmdp);
> }
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index cba29131bccc..a8788b404266 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -51,6 +51,10 @@
>
> #include <mm/mmu_decl.h>
>
> +void __weak fixup_pgtable_fragments(void)
> +{
> +}
> +
> #ifndef CPU_FTR_COHERENT_ICACHE
> #define CPU_FTR_COHERENT_ICACHE 0 /* XXX for now */
> #define CPU_FTR_NOEXECUTE 0
> @@ -276,6 +280,7 @@ void __init mem_init(void)
> set_max_mapnr(max_pfn);
> memblock_free_all();
>
> + fixup_pgtable_fragments();
> #ifdef CONFIG_HIGHMEM
> {
> unsigned long pfn, highmem_mapnr;
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH] powerpc/64s/radix: Define arch_ioremap_p4d_supported()
From: Christophe Leroy @ 2019-06-27 4:38 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Stephen Rothwell, Aneesh Kumar K.V, linux-kernel, Nicholas Piggin,
linux-next, Paul Mackerras, Andrew Morton, linuxppc-dev
In-Reply-To: <1561555260-17335-1-git-send-email-anshuman.khandual@arm.com>
On 06/26/2019 01:21 PM, Anshuman Khandual wrote:
> Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
> provide arch_ioremap_p4d_supported() failing which will result in a build
> failure like the following.
>
> ld: lib/ioremap.o: in function `.ioremap_huge_init':
> ioremap.c:(.init.text+0x3c): undefined reference to
> `.arch_ioremap_p4d_supported'
>
> This defines a stub implementation for arch_ioremap_p4d_supported() keeping
> it disabled for now to fix the build problem.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-next@vger.kernel.org
>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Add a Fixes: tag ? For instance:
Fixes: d909f9109c30 ("powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAP")
Christophe
> ---
> This has been just build tested and fixes the problem reported earlier.
>
> arch/powerpc/mm/book3s64/radix_pgtable.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 8904aa1..c81da88 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -1124,6 +1124,11 @@ void radix__ptep_modify_prot_commit(struct vm_area_struct *vma,
> set_pte_at(mm, addr, ptep, pte);
> }
>
> +int __init arch_ioremap_p4d_supported(void)
> +{
> + return 0;
> +}
> +
> int __init arch_ioremap_pud_supported(void)
> {
> /* HPT does not cope with large pages in the vmalloc area */
>
^ permalink raw reply
* Re: [PATCH] powerpc/64s/radix: Define arch_ioremap_p4d_supported()
From: Michael Ellerman @ 2019-06-27 4:48 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm
Cc: Stephen Rothwell, Anshuman Khandual, linux-kernel,
Nicholas Piggin, linux-next, Paul Mackerras, Aneesh Kumar K.V,
Andrew Morton, linuxppc-dev
In-Reply-To: <1561555260-17335-1-git-send-email-anshuman.khandual@arm.com>
Anshuman Khandual <anshuman.khandual@arm.com> writes:
> Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
> provide arch_ioremap_p4d_supported() failing which will result in a build
> failure like the following.
>
> ld: lib/ioremap.o: in function `.ioremap_huge_init':
> ioremap.c:(.init.text+0x3c): undefined reference to
> `.arch_ioremap_p4d_supported'
>
> This defines a stub implementation for arch_ioremap_p4d_supported() keeping
> it disabled for now to fix the build problem.
The easiest option is for this to be folded into your patch that creates
the requirement for arch_ioremap_p4d_supported().
Andrew might do that for you, or you could send a v2.
This looks fine from a powerpc POV:
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-next@vger.kernel.org
>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This has been just build tested and fixes the problem reported earlier.
>
> arch/powerpc/mm/book3s64/radix_pgtable.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 8904aa1..c81da88 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -1124,6 +1124,11 @@ void radix__ptep_modify_prot_commit(struct vm_area_struct *vma,
> set_pte_at(mm, addr, ptep, pte);
> }
>
> +int __init arch_ioremap_p4d_supported(void)
> +{
> + return 0;
> +}
> +
> int __init arch_ioremap_pud_supported(void)
> {
> /* HPT does not cope with large pages in the vmalloc area */
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] powerpc/rtas: retry when cpu offline races with suspend/migration
From: Michael Ellerman @ 2019-06-27 5:01 UTC (permalink / raw)
To: Juliet Kim, Nathan Lynch; +Cc: ego, mmc, linuxppc-dev
In-Reply-To: <5614fafb-43c3-1dca-1853-51ff0940fb74@linux.vnet.ibm.com>
Juliet Kim <julietk@linux.vnet.ibm.com> writes:
> On 6/25/19 1:51 PM, Nathan Lynch wrote:
>> Juliet Kim <julietk@linux.vnet.ibm.com> writes:
>>
>>> There's some concern this could retry forever, resulting in live lock.
>> First of all the system will make progress in other areas even if there
>> are repeated retries; we're not indefinitely holding locks or anything
>> like that.
>
> For instance, system admin runs a script that picks and offlines CPUs in a
> loop to keep a certain rate of onlined CPUs for energy saving. If LPM keeps
> putting CPUs back online, that would never finish, and would keepgenerating
> new offline requests
>
>> Second, Linux checks the H_VASI_STATE result on every retry. If the
>> platform wants to terminate the migration (say, if it imposes a
>> timeout), Linux will abandon it when H_VASI_STATE fails to return
>> H_VASI_SUSPENDING. And it seems incorrect to bail out before that
>> happens, absent hard errors on the Linux side such as allocation
>> failures.
> I confirmed with the PHYP and HMC folks that they wouldn't time out the LPM
> request including H_VASI_STATE, so if the LPM retries were unlucky enough to
> encounter repeated CPU offline attempts (maybe some customer code retrying
> that), then the retries could continue indefinitely, or until some manual
> intervention. And in the mean time, the LPM delay here would cause PHYP to
> block other operations.
That sounds like a PHYP bug to me.
cheers
^ permalink raw reply
* [PATCH 2/4] powerpc/cacheinfo: name@unit instead of full DT path in debug messages
From: Nathan Lynch @ 2019-06-27 5:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627051537.7298-1-nathanl@linux.ibm.com>
We know that every OF node we deal with in this code is under /cpus,
so we can make the debug messages a little less verbose without losing
information.
E.g.
cacheinfo: creating L1 dcache and icache for /cpus/PowerPC,POWER8@0
cacheinfo: creating L2 ucache for /cpus/l2-cache@2006
cacheinfo: creating L3 ucache for /cpus/l3-cache@3106
becomes
cacheinfo: creating L1 dcache and icache for PowerPC,POWER8@0
cacheinfo: creating L2 ucache for l2-cache@2006
cacheinfo: creating L3 ucache for l3-cache@3106
Replace all '%pOF' specifiers with '%pOFP'.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 295af19e00f0..d8200f7e1075 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -171,7 +171,7 @@ static void release_cache_debugcheck(struct cache *cache)
list_for_each_entry(iter, &cache_list, list)
WARN_ONCE(iter->next_local == cache,
- "cache for %pOF(%s) refers to cache for %pOF(%s)\n",
+ "cache for %pOFP(%s) refers to cache for %pOFP(%s)\n",
iter->ofnode,
cache_type_string(iter),
cache->ofnode,
@@ -183,7 +183,7 @@ static void release_cache(struct cache *cache)
if (!cache)
return;
- pr_debug("freeing L%d %s cache for %pOF\n", cache->level,
+ pr_debug("freeing L%d %s cache for %pOFP\n", cache->level,
cache_type_string(cache), cache->ofnode);
release_cache_debugcheck(cache);
@@ -198,7 +198,7 @@ static void cache_cpu_set(struct cache *cache, int cpu)
while (next) {
WARN_ONCE(cpumask_test_cpu(cpu, &next->shared_cpu_map),
- "CPU %i already accounted in %pOF(%s)\n",
+ "CPU %i already accounted in %pOFP(%s)\n",
cpu, next->ofnode,
cache_type_string(next));
cpumask_set_cpu(cpu, &next->shared_cpu_map);
@@ -359,7 +359,7 @@ static int cache_is_unified_d(const struct device_node *np)
*/
static struct cache *cache_do_one_devnode_unified(struct device_node *node, int level)
{
- pr_debug("creating L%d ucache for %pOF\n", level, node);
+ pr_debug("creating L%d ucache for %pOFP\n", level, node);
return new_cache(cache_is_unified_d(node), level, node);
}
@@ -369,7 +369,7 @@ static struct cache *cache_do_one_devnode_split(struct device_node *node,
{
struct cache *dcache, *icache;
- pr_debug("creating L%d dcache and icache for %pOF\n", level,
+ pr_debug("creating L%d dcache and icache for %pOFP\n", level,
node);
dcache = new_cache(CACHE_TYPE_DATA, level, node);
@@ -740,13 +740,13 @@ static void cacheinfo_create_index_opt_attrs(struct cache_index_dir *dir)
rc = attr->show(&dir->kobj, attr, buf);
if (rc <= 0) {
pr_debug("not creating %s attribute for "
- "%pOF(%s) (rc = %zd)\n",
+ "%pOFP(%s) (rc = %zd)\n",
attr->attr.name, cache->ofnode,
cache_type, rc);
continue;
}
if (sysfs_create_file(&dir->kobj, &attr->attr))
- pr_debug("could not create %s attribute for %pOF(%s)\n",
+ pr_debug("could not create %s attribute for %pOFP(%s)\n",
attr->attr.name, cache->ofnode, cache_type);
}
@@ -862,7 +862,7 @@ static void cache_cpu_clear(struct cache *cache, int cpu)
struct cache *next = cache->next_local;
WARN_ONCE(!cpumask_test_cpu(cpu, &cache->shared_cpu_map),
- "CPU %i not accounted in %pOF(%s)\n",
+ "CPU %i not accounted in %pOFP(%s)\n",
cpu, cache->ofnode,
cache_type_string(cache));
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] powerpc/cacheinfo: set pr_fmt
From: Nathan Lynch @ 2019-06-27 5:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627051537.7298-1-nathanl@linux.ibm.com>
Set pr_fmt so we get a nice prefix on messages.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 42c559efe060..295af19e00f0 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -10,6 +10,8 @@
* 2 as published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) "cacheinfo: " fmt
+
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/kernel.h>
--
2.20.1
^ permalink raw reply related
* [PATCH 0/4] cacheinfo instrumentation tweaks
From: Nathan Lynch @ 2019-06-27 5:15 UTC (permalink / raw)
To: linuxppc-dev
A few changes that would have aided debugging this code's interactions
with partition migration, maybe they'll help with the next thing
(hibernation?).
Nathan Lynch (4):
powerpc/cacheinfo: set pr_fmt
powerpc/cacheinfo: name@unit instead of full DT path in debug messages
powerpc/cacheinfo: improve diagnostics about malformed cache lists
powerpc/cacheinfo: warn if cache object chain becomes unordered
arch/powerpc/kernel/cacheinfo.c | 37 ++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 10 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 3/4] powerpc/cacheinfo: improve diagnostics about malformed cache lists
From: Nathan Lynch @ 2019-06-27 5:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627051537.7298-1-nathanl@linux.ibm.com>
If we have a bug which causes us to start with the wrong kind of OF
node when linking up the cache tree, it's helpful for debugging to
print information about what we found vs what we expected. So replace
uses of WARN_ON_ONCE with WARN_ONCE, which lets us include an
informative message instead of a contentless backtrace.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index d8200f7e1075..30be2cdc8aa9 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -429,8 +429,14 @@ static void link_cache_lists(struct cache *smaller, struct cache *bigger)
static void do_subsidiary_caches_debugcheck(struct cache *cache)
{
- WARN_ON_ONCE(cache->level != 1);
- WARN_ON_ONCE(!of_node_is_type(cache->ofnode, "cpu"));
+ WARN_ONCE(cache->level != 1,
+ "instantiating cache chain from L%d %s cache for "
+ "%pOFP instead of an L1\n", cache->level,
+ cache_type_string(cache), cache->ofnode);
+ WARN_ONCE(!of_node_is_type(cache->ofnode, "cpu"),
+ "instantiating cache chain from node %pOFP of type '%s' "
+ "instead of a cpu node\n", cache->ofnode,
+ of_node_get_device_type(cache->ofnode));
}
static void do_subsidiary_caches(struct cache *cache)
--
2.20.1
^ permalink raw reply related
* [PATCH 4/4] powerpc/cacheinfo: warn if cache object chain becomes unordered
From: Nathan Lynch @ 2019-06-27 5:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627051537.7298-1-nathanl@linux.ibm.com>
This can catch cases where the device tree has gotten mishandled into
an inconsistent state at runtime, e.g. the cache nodes for both the
source and the destination are present after a migration.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/cacheinfo.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 30be2cdc8aa9..5938aeeba8c0 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -425,6 +425,15 @@ static void link_cache_lists(struct cache *smaller, struct cache *bigger)
}
smaller->next_local = bigger;
+
+ /*
+ * The cache->next_local list sorts by level ascending:
+ * L1d -> L1i -> L2 -> L3 ...
+ */
+ WARN_ONCE((smaller->level == 1 && bigger->level > 2) ||
+ (smaller->level > 1 && bigger->level != smaller->level + 1),
+ "linking L%i cache %pOFP to L%i cache %pOFP; skipped a level?\n",
+ smaller->level, smaller->ofnode, bigger->level, bigger->ofnode);
}
static void do_subsidiary_caches_debugcheck(struct cache *cache)
--
2.20.1
^ permalink raw reply related
* [PATCH] powerpc/configs: Disable /dev/port in skiroot defconfig
From: Daniel Axtens @ 2019-06-27 5:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Daniel Axtens
While reviewing lockdown patches, I discovered that we still enable
/dev/port (CONFIG_DEVPORT) in skiroot.
We don't need it. Deselect CONFIG_DEVPORT for skiroot.
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
arch/powerpc/configs/skiroot_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
index 5ba131c30f6b..b2e8f37156eb 100644
--- a/arch/powerpc/configs/skiroot_defconfig
+++ b/arch/powerpc/configs/skiroot_defconfig
@@ -212,6 +212,7 @@ CONFIG_IPMI_WATCHDOG=y
CONFIG_HW_RANDOM=y
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_I2C_NUVOTON=y
+# CONFIG_DEVPORT is not set
CONFIG_I2C=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/pseries/mobility: add pr_debug for device tree changes
From: Nathan Lynch @ 2019-06-27 5:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627053044.9238-1-nathanl@linux.ibm.com>
When investigating issues with partition migration or resource
reassignments it is helpful to have a log of which nodes and
properties in the device tree have changed. Use pr_debug() so it's
easy to enable these at runtime with the dynamic debug facility.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index f9a1287925a8..5270ac00279b 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -69,6 +69,8 @@ static int delete_dt_node(__be32 phandle)
if (!dn)
return -ENOENT;
+ pr_debug("removing node %pOFfp\n", dn);
+
dlpar_detach_node(dn);
of_node_put(dn);
return 0;
@@ -127,6 +129,7 @@ static int update_dt_property(struct device_node *dn, struct property **prop,
}
if (!more) {
+ pr_debug("updating node %pOF property %s\n", dn, name);
of_update_property(dn, new_prop);
*prop = NULL;
}
@@ -241,6 +244,8 @@ static int add_dt_node(__be32 parent_phandle, __be32 drc_index)
if (rc)
dlpar_free_cc_nodes(dn);
+ pr_debug("added node %pOFfp\n", dn);
+
of_node_put(parent_dn);
return rc;
}
@@ -256,6 +261,7 @@ static void prrn_update_node(__be32 phandle)
*/
dn = of_find_node_by_phandle(be32_to_cpu(phandle));
if (dn) {
+ pr_debug("ignoring PRRN for %pOFfp\n", dn);
of_node_put(dn);
return;
}
@@ -265,6 +271,8 @@ static void prrn_update_node(__be32 phandle)
hp_elog.id_type = PSERIES_HP_ELOG_ID_DRC_INDEX;
hp_elog._drc_u.drc_index = phandle;
+ pr_debug("handling PRRN for LMB DRC index 0x%x\n", be32_to_cpu(phandle));
+
handle_dlpar_errorlog(&hp_elog);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/pseries/mobility: set pr_fmt
From: Nathan Lynch @ 2019-06-27 5:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190627053044.9238-1-nathanl@linux.ibm.com>
The pr_err callsites in mobility.c already manually include a
"mobility:" prefix, let's make it official for the benefit of messages
to be added later.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index b8c8096907d4..f9a1287925a8 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -9,6 +9,9 @@
* 2 as published by the Free Software Foundation.
*/
+
+#define pr_fmt(fmt) "mobility: " fmt
+
#include <linux/cpu.h>
#include <linux/kernel.h>
#include <linux/kobject.h>
@@ -418,11 +421,11 @@ static int __init mobility_sysfs_init(void)
rc = sysfs_create_file(mobility_kobj, &class_attr_migration.attr);
if (rc)
- pr_err("mobility: unable to create migration sysfs file (%d)\n", rc);
+ pr_err("unable to create migration sysfs file (%d)\n", rc);
rc = sysfs_create_file(mobility_kobj, &class_attr_api_version.attr.attr);
if (rc)
- pr_err("mobility: unable to create api_version sysfs file (%d)\n", rc);
+ pr_err("unable to create api_version sysfs file (%d)\n", rc);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 0/2] migration/prrn instrumentation tweaks
From: Nathan Lynch @ 2019-06-27 5:30 UTC (permalink / raw)
To: linuxppc-dev
Mainly this produces better information about what's happening with
the device tree as a result of LPM or PRRN.
Nathan Lynch (2):
powerpc/pseries/mobility: set pr_fmt
powerpc/pseries/mobility: add pr_debug for device tree changes
arch/powerpc/platforms/pseries/mobility.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] recordmcount: Fix spurious mcount entries on powerpc
From: Michael Ellerman @ 2019-06-27 5:55 UTC (permalink / raw)
To: Naveen N. Rao, Steven Rostedt, Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20190626183801.31247-1-naveen.n.rao@linux.vnet.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> The recent change enabling HAVE_C_RECORDMCOUNT on powerpc started
> showing the following issue:
>
> # modprobe kprobe_example
> ftrace-powerpc: Not expected bl: opcode is 3c4c0001
> WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318
> Modules linked in:
> CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2
> NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30
> REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942)
> MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228222 XER: 00000000
> CFAR: c0000000002642fc IRQMASK: 0
> <snip>
> NIP [c000000000264318] ftrace_bug+0x90/0x318
> LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
> Call Trace:
> [c000000001f2ba40] [0000000000000004] 0x4 (unreliable)
> [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
> [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0
> [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130
> [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70
> Instruction dump:
> 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96
> 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96
> ---[ end trace 4c438d5cebf78381 ]---
> ftrace failed to modify
> [<c0080000012a0008>] 0xc0080000012a0008
> actual: 01:00:4c:3c
> Initializing ftrace call sites
> ftrace record flags: 2000000
> (0)
> expected tramp: c00000000006af4c
Aha, thanks. I saw that on one of my text boxes but hadn't pinned it
down to this commit.
> Fixes: c7d64b560ce80 ("powerpc/ftrace: Enable C Version of recordmcount")
That commit is the tip of my next, so I'll drop it for now and merge
them in the other order so there's breakage.
Steve are you OK if I merge this via the powerpc tree? I'll reword the
commit message so that it makes sense coming prior to the commit
mentioned above.
cheers
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> scripts/recordmcount.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 13c5e6c8829c..47fca2c69a73 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -325,7 +325,8 @@ static uint_t *sift_rel_mcount(uint_t *mlocp,
> if (!mcountsym)
> mcountsym = get_mcountsym(sym0, relp, str0);
>
> - if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
> + if (mcountsym && mcountsym == Elf_r_sym(relp) &&
> + !is_fake_mcount(relp)) {
> uint_t const addend =
> _w(_w(relp->r_offset) - recval + mcount_adjust);
> mrelp->r_offset = _w(offbase
> --
> 2.22.0
^ permalink raw reply
* Re: [PATCH V2] crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
From: Herbert Xu @ 2019-06-27 6:26 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, linux-crypto, stable
In-Reply-To: <1560884962.22818.9.camel@hbabu-laptop>
Haren Myneni <haren@linux.vnet.ibm.com> wrote:
>
> System gets checkstop if RxFIFO overruns with more requests than the
> maximum possible number of CRBs in FIFO at the same time. The max number
> of requests per window is controlled by window credits. So find max
> CRBs from FIFO size and set it to receive window credits.
>
> Fixes: b0d6c9bab5e4 ("crypto/nx: Add P9 NX support for 842 compression engine")
> CC: stable@vger.kernel.org # v4.14+
> Signed-off-by:Haren Myneni <haren@us.ibm.com>
I presume this is being picked up by the powerpc tree?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox