Re: [PATCH] cxl: use pcibios_free_controller_deferred() when removing vPHBs
On Tue, 2016-08-30 at 11:58 +1000, Andrew Donnellan wrote: > Hi stable team, > > The following patch, which ended up upstream as > 6f38a8b9a45833495dc878c335c5431cd98a16ed: > > On 18/08/16 17:35, Andrew Donnellan wrote: > > > > When cxl removes a vPHB, it's possible that the pci_controller may be freed > > before all references to the devices on the vPHB have been released. This > > in turn causes an invalid memory access when the devices are eventually > > released, as pcibios_release_device() attempts to call the phb's > > release_device hook. > > > > In cxl_pci_vphb_remove(), remove the existing call to > > pcibios_free_controller(). Instead, use > > pcibios_free_controller_deferred() to free the pci_controller after all > > devices have been released. Export pci_set_host_bridge_release() so we can > > do this. > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Andrew Donnellan > > > > --- > > > > > > This patch requires http://patchwork.ozlabs.org/patch/658324/. It > > > > should go > > through the powerpc tree. > > This depends on 2dd9c11b9d4dfbd6c070eab7b81197f65e82f1a0 which didn't > end up being tagged as cc: stable. It also ended up being applied in the > wrong order in the powerpc/fixes tree... My fault. Best at this point is to also apply 2dd9c11b9d4dfbd6c070eab7b81197f65e82f1a0 to stable. Cheers, Ben.
Re: [PATCH] cxl: use pcibios_free_controller_deferred() when removing vPHBs
Hi stable team, The following patch, which ended up upstream as 6f38a8b9a45833495dc878c335c5431cd98a16ed: On 18/08/16 17:35, Andrew Donnellan wrote: When cxl removes a vPHB, it's possible that the pci_controller may be freed before all references to the devices on the vPHB have been released. This in turn causes an invalid memory access when the devices are eventually released, as pcibios_release_device() attempts to call the phb's release_device hook. In cxl_pci_vphb_remove(), remove the existing call to pcibios_free_controller(). Instead, use pcibios_free_controller_deferred() to free the pci_controller after all devices have been released. Export pci_set_host_bridge_release() so we can do this. Cc: sta...@vger.kernel.org Signed-off-by: Andrew Donnellan --- This patch requires http://patchwork.ozlabs.org/patch/658324/. It should go through the powerpc tree. This depends on 2dd9c11b9d4dfbd6c070eab7b81197f65e82f1a0 which didn't end up being tagged as cc: stable. It also ended up being applied in the wrong order in the powerpc/fixes tree... Thanks, -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnel...@au1.ibm.com IBM Australia Limited
Re: Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1
El Mon, Aug 29, 2016 at 12:28:21PM -0700, Nicolin Chen deia: > > Yes, it seems that it also tried to correct the clock sources > as those were not available when adding the S/PDIF support at > the first place. > I wonder if maybe they need to be defined, assigned or somehow listed elsewhere and they are not for wandboard quad (but are for other boards)? > > The issue is fixed for me with this patch but I'm not sure what's the > > best way to help fix any issue someone else may have or what other > > info or test you might need. Any guidance welcome. > > > --- linux-4.7-no-spdif-out/arch/arm/boot/dts/imx6qdl.dtsi 2016-07-25 > > 00:19:43.0 +0200 > > +++ linux-4.7/arch/arm/boot/dts/imx6qdl.dtsi2016-08-28 > > 17:59:14.276774409 +0200 > > @@ -240,9 +240,9 @@ > ><&sdma 15 18 0>; > > dma-names = "rx", "tx"; > > clocks = <&clks > > IMX6QDL_CLK_SPDIF_GCLK>, <&clks IMX6QDL_CLK_OSC>, > > -<&clks IMX6QDL_CLK_SPDIF>, > > <&clks IMX6QDL_CLK_ASRC>, > > -<&clks IMX6QDL_CLK_DUMMY>, > > <&clks IMX6QDL_CLK_ESAI_EXTAL>, > > -<&clks IMX6QDL_CLK_IPG>, > > <&clks IMX6QDL_CLK_MLB>, > > +<&clks IMX6QDL_CLK_SPDIF>, > > <&clks IMX6QDL_CLK_DUMMY>, > > +<&clks IMX6QDL_CLK_DUMMY>, > > <&clks IMX6QDL_CLK_DUMMY>, > > +<&clks IMX6QDL_CLK_DUMMY>, > > <&clks IMX6QDL_CLK_DUMMY>, > > <&clks IMX6QDL_CLK_DUMMY>, > > <&clks IMX6QDL_CLK_SPBA>; > > clock-names = "core", "rxtx0", > > "rxtx1", "rxtx2", > > This looks like that you merely revert the SPDIF_GCLK. I revert only some clocks, yes. I left SPDIF_GCLK and CLK_SBPA intact. So it is a partial revert of the commit. > Would you > please do a little debug using "#define DEBUG 1" and check printk > from fsl_spdif_probe_txclk() to see the difference between before > and after Shengjiu's commit? Yes, but I'm compiling the kernel in the wandboard, so it'll take me some time. Thank you.
Re: [PATCH v3 0/3] Account reserved memory when allocating system hash
On Mon, 29 Aug 2016 18:36:47 +0530 Srikar Dronamraju wrote: > Fadump kernel reserves large chunks of memory even before the pages are > initialised. This could mean memory that corresponds to several nodes might > fall in memblock reserved regions. > > Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise > only certain size memory per node. The certain size takes into account > the dentry and inode cache sizes. However such a kernel when booting a > secondary kernel will not be able to allocate the required amount of > memory to suffice for the dentry and inode caches. This results in > crashes like the below on large systems such as 32 TB systems. > > Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes) > vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes > swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC) > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3 > Call Trace: > [c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable) > [c108fb50] [c0235264] warn_alloc_failed+0x114/0x160 > [c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340 > [c108fca0] [c028152c] __vmalloc+0x6c/0x90 > [c108fd40] [c0aecfb0] > alloc_large_system_hash+0x1b8/0x2c0 > [c108fe00] [c0af7240] inode_init+0x94/0xe4 > [c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c > [c108ff00] [c0ac4014] start_kernel+0x50c/0x578 > [c108ff90] [c0008c6c] start_here_common+0x20/0xa8 > > This patchset solves this problem by accounting the size of reserved memory > when calculating the size of large system hashes. What's the priority on this, btw? Not needed in earlier kernels?
Re: [PATCH v3 0/3] Account reserved memory when allocating system hash
On Mon, 29 Aug 2016 18:36:47 +0530 Srikar Dronamraju wrote: > Fadump kernel reserves large chunks of memory even before the pages are > initialised. This could mean memory that corresponds to several nodes might > fall in memblock reserved regions. > > Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise > only certain size memory per node. The certain size takes into account > the dentry and inode cache sizes. However such a kernel when booting a > secondary kernel will not be able to allocate the required amount of > memory to suffice for the dentry and inode caches. This results in > crashes like the below on large systems such as 32 TB systems. > > Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes) > vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes > swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC) > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3 > Call Trace: > [c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable) > [c108fb50] [c0235264] warn_alloc_failed+0x114/0x160 > [c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340 > [c108fca0] [c028152c] __vmalloc+0x6c/0x90 > [c108fd40] [c0aecfb0] > alloc_large_system_hash+0x1b8/0x2c0 > [c108fe00] [c0af7240] inode_init+0x94/0xe4 > [c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c > [c108ff00] [c0ac4014] start_kernel+0x50c/0x578 > [c108ff90] [c0008c6c] start_here_common+0x20/0xa8 > > This patchset solves this problem by accounting the size of reserved memory > when calculating the size of large system hashes. > > While this patchset applies on v4.8-rc3, it cannot be tested on v4.8-rc3 > because of http://lkml.kernel.org/r/20160829093844.ga2...@linux.vnet.ibm.com > However it has been tested on v4.7/v4.6 and v4.4 That looks like a pretty serious regression. I'll grab the patchset anyway. It will come good when we fix that kswapd thing.
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag
On Mon, 2016-08-29 at 12:15 -0700, Linus Torvalds wrote: > On Sun, Aug 28, 2016 at 9:44 PM, Benjamin Herrenschmidt > > wrote: > > > > > > This is my first signed-tag and use of 2fa so I hope I got it all right... > > I tried to use the same format Michael uses for the tag etc... > > The signature all looks fine, but when the contents of the tag are > just the same git information that you can get from git itself, it's > not useful as a merge message. So I prefer the actual high-level "what > changed" message instead: > > > > > We have some misc fixes for powerpc 4.8. Some trivial bits and some > > regressions, and a trivial cleanup or two that I saw no point in letting > > rot in patchwork. > > .. although optimally with a *bit* more detail. > > Anyway, pulled. Ok. Will fix that next time. Cheers, Ben.
Re: Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1
Added Fabio as I can't test S/PDIF on my board. On Sun, Aug 28, 2016 at 06:00:55PM +0200, Xavi Drudis Ferran wrote: > I was using linux-libre-3.19 (implies no working sdma) with a > wandboard quad (Freescale imx6q). Spidf output worked fine. > > When I upgraded to linux-libre-4.7 spdif output was supressed without > any error (precisely, with the same errors about sdma that 3.19 gave). > > I saw someone else reporting the same elsewhere with linux-4.4 > https://forum.digikey.com/thread/34240 > (but I don't have a login there) > > This patch fixes it for me and sound works again on spdif. > > But I don't know if it can break (or fix?) something for some other > boards or kernels or cases... I hardly know what I'm doing. > The commits that might have caused the problem for me might be > > commit 833f2cbf7091099baee28136dc68678e974c0ac5 > Author: Shengjiu Wang > Date: Sat Oct 10 18:15:07 2015 +0800 > > ARM: dts: imx6: change the core clock of spdif > > The correct core clock of spdif is SPDIF_GCLK, which is added to > clock tree. So the dts also need to be updated. > > Signed-off-by: Shengjiu Wang > Signed-off-by: Shawn Guo > > (the commit changed more clocks than SPDIF_GCLK) Yes, it seems that it also tried to correct the clock sources as those were not available when adding the S/PDIF support at the first place. > The issue is fixed for me with this patch but I'm not sure what's the > best way to help fix any issue someone else may have or what other > info or test you might need. Any guidance welcome. > --- linux-4.7-no-spdif-out/arch/arm/boot/dts/imx6qdl.dtsi 2016-07-25 > 00:19:43.0 +0200 > +++ linux-4.7/arch/arm/boot/dts/imx6qdl.dtsi 2016-08-28 17:59:14.276774409 > +0200 > @@ -240,9 +240,9 @@ > <&sdma 15 18 0>; > dma-names = "rx", "tx"; > clocks = <&clks > IMX6QDL_CLK_SPDIF_GCLK>, <&clks IMX6QDL_CLK_OSC>, > - <&clks IMX6QDL_CLK_SPDIF>, > <&clks IMX6QDL_CLK_ASRC>, > - <&clks IMX6QDL_CLK_DUMMY>, > <&clks IMX6QDL_CLK_ESAI_EXTAL>, > - <&clks IMX6QDL_CLK_IPG>, > <&clks IMX6QDL_CLK_MLB>, > + <&clks IMX6QDL_CLK_SPDIF>, > <&clks IMX6QDL_CLK_DUMMY>, > + <&clks IMX6QDL_CLK_DUMMY>, > <&clks IMX6QDL_CLK_DUMMY>, > + <&clks IMX6QDL_CLK_DUMMY>, > <&clks IMX6QDL_CLK_DUMMY>, ><&clks IMX6QDL_CLK_DUMMY>, > <&clks IMX6QDL_CLK_SPBA>; > clock-names = "core", "rxtx0", > "rxtx1", "rxtx2", This looks like that you merely revert the SPDIF_GCLK. Would you please do a little debug using "#define DEBUG 1" and check printk from fsl_spdif_probe_txclk() to see the difference between before and after Shengjiu's commit?
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag
On Sun, Aug 28, 2016 at 9:44 PM, Benjamin Herrenschmidt wrote: > > This is my first signed-tag and use of 2fa so I hope I got it all right... > I tried to use the same format Michael uses for the tag etc... The signature all looks fine, but when the contents of the tag are just the same git information that you can get from git itself, it's not useful as a merge message. So I prefer the actual high-level "what changed" message instead: > We have some misc fixes for powerpc 4.8. Some trivial bits and some > regressions, and a trivial cleanup or two that I saw no point in letting > rot in patchwork. .. although optimally with a *bit* more detail. Anyway, pulled. Linus
Re: hwrng: pasemi_rng.c: Migrate to managed API
Hello PrasannaKumar On 25/08/2016, PrasannaKumar Muralidharan wrote: >> I will propose to use devm_ioremap_resource() instead for removing this >> hardcoded 0x100, but i cannot find any user of this driver in any dts. >> (And so cannot check that this 0x100 is given in any DT resource node) > >> Is this normal ? > > I wanted to use devm_ioremap_resource but could not find DT entry > required for this driver in any of the .dts files. So did not change > that. I could not find any dts/dtsi for this platform. So I assume > that the dtb is not present in the kernel, dtb is supplied by the > bootloader. I may be wrong in this. Can anyone confirm this? On mine (Amigaone X1000) that is correct, we boot linux with a vmlinux file, and the bootloader (CFE) passes a fixed dtb. I think it is possible to dump the tree from inside CFE, if it would help I can invetigate? Regards Darren
Re: [PATCH 0/2] Support non-ssi cpu-dai for sgtl5000
On Mon, Aug 29, 2016 at 7:51 AM, Winter Wang wrote: > These patches support sgtl5000 to be attached to other non-ssi cpu-dais like > SAI. Do we really need this? We can use SAI with sgtl5000 just fine via simple card. Take a look at: https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/arch/arm/boot/dts/imx6ul-14x14-evk.dts?h=imx/fixes&id=bf3251e112a0139c8dec796c9f12f2e8f01a73ca
Re: [PATCH kernel 14/15] vfio/spapr_tce: Export container API for external users
On Mon, Aug 29, 2016 at 04:35:15PM +1000, Alexey Kardashevskiy wrote:
> On 18/08/16 10:22, Alexey Kardashevskiy wrote:
> > On 17/08/16 13:17, David Gibson wrote:
> >> On Fri, Aug 12, 2016 at 09:22:01AM -0600, Alex Williamson wrote:
> >>> On Fri, 12 Aug 2016 15:46:01 +1000
> >>> David Gibson wrote:
> >>>
> On Wed, Aug 10, 2016 at 10:46:30AM -0600, Alex Williamson wrote:
> > On Wed, 10 Aug 2016 15:37:17 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> On 09/08/16 22:16, Alex Williamson wrote:
> >>> On Tue, 9 Aug 2016 15:19:39 +1000
> >>> Alexey Kardashevskiy wrote:
> >>>
> On 09/08/16 02:43, Alex Williamson wrote:
> > On Wed, 3 Aug 2016 18:40:55 +1000
> > Alexey Kardashevskiy wrote:
> >
> >> This exports helpers which are needed to keep a VFIO container in
> >> memory while there are external users such as KVM.
> >>
> >> Signed-off-by: Alexey Kardashevskiy
> >> ---
> >> drivers/vfio/vfio.c | 30
> >> ++
> >> drivers/vfio/vfio_iommu_spapr_tce.c | 16 +++-
> >> include/linux/vfio.h| 6 ++
> >> 3 files changed, 51 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >> index d1d70e0..baf6a9c 100644
> >> --- a/drivers/vfio/vfio.c
> >> +++ b/drivers/vfio/vfio.c
> >> @@ -1729,6 +1729,36 @@ long vfio_external_check_extension(struct
> >> vfio_group *group, unsigned long arg)
> >> EXPORT_SYMBOL_GPL(vfio_external_check_extension);
> >>
> >> /**
> >> + * External user API for containers, exported by symbols to be
> >> linked
> >> + * dynamically.
> >> + *
> >> + */
> >> +struct vfio_container *vfio_container_get_ext(struct file *filep)
> >> +{
> >> + struct vfio_container *container = filep->private_data;
> >> +
> >> + if (filep->f_op != &vfio_fops)
> >> + return ERR_PTR(-EINVAL);
> >> +
> >> + vfio_container_get(container);
> >> +
> >> + return container;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_get_ext);
> >> +
> >> +void vfio_container_put_ext(struct vfio_container *container)
> >> +{
> >> + vfio_container_put(container);
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_put_ext);
> >> +
> >> +void *vfio_container_get_iommu_data_ext(struct vfio_container
> >> *container)
> >> +{
> >> + return container->iommu_data;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_get_iommu_data_ext);
> >> +
> >> +/**
> >> * Sub-module support
> >> */
> >> /*
> >> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
> >> b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> index 3594ad3..fceea3d 100644
> >> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> >> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> >> @@ -1331,6 +1331,21 @@ const struct vfio_iommu_driver_ops
> >> tce_iommu_driver_ops = {
> >>.detach_group = tce_iommu_detach_group,
> >> };
> >>
> >> +struct iommu_table *vfio_container_spapr_tce_table_get_ext(void
> >> *iommu_data,
> >> + u64 offset)
> >> +{
> >> + struct tce_container *container = iommu_data;
> >> + struct iommu_table *tbl = NULL;
> >> +
> >> + if (tce_iommu_find_table(container, offset, &tbl) < 0)
> >> + return NULL;
> >> +
> >> + iommu_table_get(tbl);
> >> +
> >> + return tbl;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vfio_container_spapr_tce_table_get_ext);
> >> +
> >> static int __init tce_iommu_init(void)
> >> {
> >>return vfio_register_iommu_driver(&tce_iommu_driver_ops);
> >> @@ -1348,4 +1363,3 @@ MODULE_VERSION(DRIVER_VERSION);
> >> MODULE_LICENSE("GPL v2");
> >> MODULE_AUTHOR(DRIVER_AUTHOR);
> >> MODULE_DESCRIPTION(DRIVER_DESC);
> >> -
> >> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> >> index 0ecae0b..1c2138a 100644
> >> --- a/include/linux/vfio.h
> >> +++ b/include/linux/vfio.h
> >> @@ -91,6 +91,12 @@ extern void vfio_group_put_external_user(struct
> >> vfio_group *group);
> >> extern int vfio_external_user_iommu_id(struct vfio_group *group);
> >> extern long vfio_external_check_extension(struct vfio_group
> >> *group,
> >> unsigned long arg);
> >> +extern struct vfio_container *vfio_container_get_ext(struct file
Re: [PATCH V2 2/2] fadump: Register the memory reserved by fadump
* Andrew Morton [2016-08-04 14:01:33]: > > Register the memory reserved by fadump, so that the cache sizes are > > calculated based on the free memory (i.e Total memory - reserved > > memory). > > Looks harmless enough to me. I'll schedule the patches for 4.8. But > it sounds like they should be backported into older kernels? > Based on the v2 feedback, I just posted a v3 at http://lkml.kernel.org/r/1472476010-4709-1-git-send-email-sri...@linux.vnet.ibm.com that tries to reduce the large system hash based on tha reserved memory. Hence please drop the v2 patches. -- Thanks and Regards Srikar Dronamraju
[PATCH v3 3/3] powerpc: Implement arch_reserved_kernel_pages
Currently significant amount of memory is reserved only in kernel
booted to capture kernel dump using the fa_dump method.
Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialize
only certain size memory per node. The certain size takes into account
the dentry and inode cache sizes. Currently the cache sizes are
calculated based on the total system memory including the reserved
memory. However such a kernel when booting the same kernel as fadump
kernel will not be able to allocate the required amount of memory to
suffice for the dentry and inode caches. This results in crashes like
Hence only implement arch_reserved_kernel_pages() for CONFIG_FA_DUMP
configurations. The amount reserved will be reduced while calculating
the large caches and will avoid crashes like the below on large systems
such as 32 TB systems.
Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes)
vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes
swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3
Call Trace:
[c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable)
[c108fb50] [c0235264] warn_alloc_failed+0x114/0x160
[c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340
[c108fca0] [c028152c] __vmalloc+0x6c/0x90
[c108fd40] [c0aecfb0]
alloc_large_system_hash+0x1b8/0x2c0
[c108fe00] [c0af7240] inode_init+0x94/0xe4
[c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c
[c108ff00] [c0ac4014] start_kernel+0x50c/0x578
[c108ff90] [c0008c6c] start_here_common+0x20/0xa8
Cc: linux...@kvack.org
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Andrew Morton
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar
Cc: Hari Bathini
Cc: Dave Hansen
Cc: Balbir Singh
Suggested-by: Michael Ellerman
Signed-off-by: Srikar Dronamraju
---
arch/powerpc/include/asm/mmzone.h | 3 +++
arch/powerpc/kernel/fadump.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/mmzone.h
b/arch/powerpc/include/asm/mmzone.h
index 7b58917..4d52ccf 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -41,6 +41,9 @@ u64 memory_hotplug_max(void);
#else
#define memory_hotplug_max() memblock_end_of_DRAM()
#endif /* CONFIG_NEED_MULTIPLE_NODES */
+#ifdef CONFIG_FA_DUMP
+#define __HAVE_ARCH_RESERVED_KERNEL_PAGES
+#endif
#endif /* __KERNEL__ */
#endif /* _ASM_MMZONE_H_ */
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index b3a6633..eeb80de 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -333,6 +333,11 @@ int __init fadump_reserve_mem(void)
return 1;
}
+unsigned long __init arch_reserved_kernel_pages(void)
+{
+ return memblock_reserved_size() / PAGE_SIZE;
+}
+
/* Look for fadump= cmdline option. */
static int __init early_fadump_param(char *p)
{
--
1.8.5.6
[PATCH v3 2/3] mm/memblock: Expose total reserved memory
The total reserved memory in a system is accounted but not available for
use use outside mm/memblock.c. By exposing the total reserved memory,
systems can better calculate the size of large hashes.
Cc: linux...@kvack.org
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Andrew Morton
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar
Cc: Hari Bathini
Cc: Dave Hansen
Cc: Balbir Singh
Suggested-by: Michael Ellerman
Signed-off-by: Srikar Dronamraju
---
include/linux/memblock.h | 1 +
mm/memblock.c| 5 +
2 files changed, 6 insertions(+)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 2925da2..5b759c9 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -328,6 +328,7 @@ phys_addr_t memblock_alloc_base(phys_addr_t size,
phys_addr_t align,
phys_addr_t __memblock_alloc_base(phys_addr_t size, phys_addr_t align,
phys_addr_t max_addr);
phys_addr_t memblock_phys_mem_size(void);
+phys_addr_t memblock_reserved_size(void);
phys_addr_t memblock_mem_size(unsigned long limit_pfn);
phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
diff --git a/mm/memblock.c b/mm/memblock.c
index 483197e..c8dfa43 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1438,6 +1438,11 @@ phys_addr_t __init_memblock memblock_phys_mem_size(void)
return memblock.memory.total_size;
}
+phys_addr_t __init_memblock memblock_reserved_size(void)
+{
+ return memblock.reserved.total_size;
+}
+
phys_addr_t __init memblock_mem_size(unsigned long limit_pfn)
{
unsigned long pages = 0;
--
1.8.5.6
[PATCH v3 1/3] mm: Introduce arch_reserved_kernel_pages()
Currently arch specific code can reserve memory blocks but
alloc_large_system_hash() may not take it into consideration when sizing
the hashes. This can lead to bigger hash than required and lead to no
available memory for other purposes. This is specifically true for
systems with CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled.
One approach to solve this problem would be to walk through the memblock
regions and calculate the available memory and base the size of hash
system on the available memory.
The other approach would be to depend on the architecture to provide the
number of pages that are reserved. This change provides hooks to allow
the architecture to provide the required info.
Cc: linux...@kvack.org
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Andrew Morton
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar
Cc: Hari Bathini
Cc: Dave Hansen
Cc: Balbir Singh
Suggested-by: Mel Gorman
Signed-off-by: Srikar Dronamraju
---
include/linux/mm.h | 3 +++
mm/page_alloc.c| 12
2 files changed, 15 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 08ed53e..7e91cd8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1924,6 +1924,9 @@ extern void show_mem(unsigned int flags);
extern long si_mem_available(void);
extern void si_meminfo(struct sysinfo * val);
extern void si_meminfo_node(struct sysinfo *val, int nid);
+#ifdef __HAVE_ARCH_RESERVED_KERNEL_PAGES
+extern unsigned long arch_reserved_kernel_pages(void);
+#endif
extern __printf(3, 4)
void warn_alloc_failed(gfp_t gfp_mask, unsigned int order,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3fbe73a..9d91706 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6976,6 +6976,17 @@ static int __init set_hashdist(char *str)
__setup("hashdist=", set_hashdist);
#endif
+#ifndef __HAVE_ARCH_RESERVED_KERNEL_PAGES
+/*
+ * Returns the number of pages that arch has reserved but
+ * is not known to alloc_large_system_hash().
+ */
+static unsigned long __init arch_reserved_kernel_pages(void)
+{
+ return 0;
+}
+#endif
+
/*
* allocate a large system hash table from bootmem
* - it is assumed that the hash table must contain an exact power-of-2
@@ -7000,6 +7011,7 @@ void *__init alloc_large_system_hash(const char
*tablename,
if (!numentries) {
/* round applicable memory size up to nearest megabyte */
numentries = nr_kernel_pages;
+ numentries -= arch_reserved_kernel_pages();
/* It isn't necessary when PAGE_SIZE >= 1MB */
if (PAGE_SHIFT < 20)
--
1.8.5.6
[PATCH v3 0/3] Account reserved memory when allocating system hash
Fadump kernel reserves large chunks of memory even before the pages are initialised. This could mean memory that corresponds to several nodes might fall in memblock reserved regions. Kernels compiled with CONFIG_DEFERRED_STRUCT_PAGE_INIT will initialise only certain size memory per node. The certain size takes into account the dentry and inode cache sizes. However such a kernel when booting a secondary kernel will not be able to allocate the required amount of memory to suffice for the dentry and inode caches. This results in crashes like the below on large systems such as 32 TB systems. Dentry cache hash table entries: 536870912 (order: 16, 4294967296 bytes) vmalloc: allocation failure, allocated 4097114112 of 17179934720 bytes swapper/0: page allocation failure: order:0, mode:0x2080020(GFP_ATOMIC) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6-master+ #3 Call Trace: [c108fb10] [c07fac88] dump_stack+0xb0/0xf0 (unreliable) [c108fb50] [c0235264] warn_alloc_failed+0x114/0x160 [c108fbf0] [c0281484] __vmalloc_node_range+0x304/0x340 [c108fca0] [c028152c] __vmalloc+0x6c/0x90 [c108fd40] [c0aecfb0] alloc_large_system_hash+0x1b8/0x2c0 [c108fe00] [c0af7240] inode_init+0x94/0xe4 [c108fe80] [c0af6fec] vfs_caches_init+0x8c/0x13c [c108ff00] [c0ac4014] start_kernel+0x50c/0x578 [c108ff90] [c0008c6c] start_here_common+0x20/0xa8 This patchset solves this problem by accounting the size of reserved memory when calculating the size of large system hashes. While this patchset applies on v4.8-rc3, it cannot be tested on v4.8-rc3 because of http://lkml.kernel.org/r/20160829093844.ga2...@linux.vnet.ibm.com However it has been tested on v4.7/v4.6 and v4.4 v2: http://lkml.kernel.org/r/1470330729-6273-1-git-send-email-sri...@linux.vnet.ibm.com Cc: linux...@kvack.org Cc: Mel Gorman Cc: Vlastimil Babka Cc: Michal Hocko Cc: Andrew Morton Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Cc: Mahesh Salgaonkar Cc: Hari Bathini Cc: Dave Hansen Cc: Balbir Singh Cc: Srikar Dronamraju Srikar Dronamraju (3): mm: Introduce arch_reserved_kernel_pages() mm/memblock: Expose total reserved memory powerpc: Implement arch_reserved_kernel_pages arch/powerpc/include/asm/mmzone.h | 3 +++ arch/powerpc/kernel/fadump.c | 5 + include/linux/memblock.h | 1 + include/linux/mm.h| 3 +++ mm/memblock.c | 5 + mm/page_alloc.c | 12 6 files changed, 29 insertions(+) -- 1.8.5.6
[PATCH 5/5] powerpc-MSI-HSTA: Move three assignments in hsta_msi_probe()
From: Markus Elfring
Date: Mon, 29 Aug 2016 11:30:48 +0200
Move the assignments for three data structure members to the end
so that they will only be performed if the desired resource allocations
succeeded by this function.
Signed-off-by: Markus Elfring
---
arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
index 3097ddd..57014ce 100644
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -143,10 +143,7 @@ static int hsta_msi_probe(struct platform_device *pdev)
return -EINVAL;
}
- ppc4xx_hsta_msi.dev = dev;
- ppc4xx_hsta_msi.address = mem->start;
ppc4xx_hsta_msi.data = ioremap(mem->start, resource_size(mem));
- ppc4xx_hsta_msi.irq_count = irq_count;
if (!ppc4xx_hsta_msi.data) {
dev_err(dev, "Unable to map memory\n");
return -ENOMEM;
@@ -179,6 +176,10 @@ static int hsta_msi_probe(struct platform_device *pdev)
phb->controller_ops.setup_msi_irqs = hsta_setup_msi_irqs;
phb->controller_ops.teardown_msi_irqs = hsta_teardown_msi_irqs;
}
+
+ ppc4xx_hsta_msi.dev = dev;
+ ppc4xx_hsta_msi.address = mem->start;
+ ppc4xx_hsta_msi.irq_count = irq_count;
return 0;
free_irq_map:
kfree(ppc4xx_hsta_msi.irq_map);
--
2.9.3
[PATCH 4/5] powerpc-MSI-HSTA: Rename jump labels in hsta_msi_probe()
From: Markus Elfring
Date: Mon, 29 Aug 2016 11:22:19 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
index 691db9a..3097ddd 100644
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -154,14 +154,14 @@ static int hsta_msi_probe(struct platform_device *pdev)
ret = msi_bitmap_alloc(&ppc4xx_hsta_msi.bmp, irq_count, dev->of_node);
if (ret)
- goto out;
+ goto unmap_io;
ppc4xx_hsta_msi.irq_map = kmalloc_array(irq_count,
sizeof(*ppc4xx_hsta_msi.irq_map),
GFP_KERNEL);
if (!ppc4xx_hsta_msi.irq_map) {
ret = -ENOMEM;
- goto out1;
+ goto free_bitmap;
}
/* Setup a mapping from irq offsets to hardware irq numbers */
@@ -171,7 +171,7 @@ static int hsta_msi_probe(struct platform_device *pdev)
if (ppc4xx_hsta_msi.irq_map[irq] == NO_IRQ) {
dev_err(dev, "Unable to map IRQ\n");
ret = -EINVAL;
- goto out2;
+ goto free_irq_map;
}
}
@@ -180,14 +180,11 @@ static int hsta_msi_probe(struct platform_device *pdev)
phb->controller_ops.teardown_msi_irqs = hsta_teardown_msi_irqs;
}
return 0;
-
-out2:
+ free_irq_map:
kfree(ppc4xx_hsta_msi.irq_map);
-
-out1:
+ free_bitmap:
msi_bitmap_free(&ppc4xx_hsta_msi.bmp);
-
-out:
+ unmap_io:
iounmap(ppc4xx_hsta_msi.data);
return ret;
}
--
2.9.3
[PATCH 3/5] powerpc-MSI-HSTA: Use kmalloc_array() in hsta_msi_probe()
From: Markus Elfring
Date: Mon, 29 Aug 2016 11:20:39 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
index 52a93dc..691db9a 100644
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -156,7 +156,9 @@ static int hsta_msi_probe(struct platform_device *pdev)
if (ret)
goto out;
- ppc4xx_hsta_msi.irq_map = kmalloc(sizeof(int) * irq_count, GFP_KERNEL);
+ ppc4xx_hsta_msi.irq_map = kmalloc_array(irq_count,
+
sizeof(*ppc4xx_hsta_msi.irq_map),
+ GFP_KERNEL);
if (!ppc4xx_hsta_msi.irq_map) {
ret = -ENOMEM;
goto out1;
--
2.9.3
[PATCH 2/5] powerpc-MSI: Use kmalloc_array() in ppc4xx_setup_msi_irqs()
From: Markus Elfring
Date: Mon, 29 Aug 2016 11:11:24 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/powerpc/sysdev/ppc4xx_msi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 8fb8061..0bd5e4b 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -89,7 +89,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
if (type == PCI_CAP_ID_MSIX)
pr_debug("ppc4xx msi: MSI-X untested, trying anyway.\n");
- msi_data->msi_virqs = kmalloc((msi_irqs) * sizeof(int), GFP_KERNEL);
+ msi_data->msi_virqs = kmalloc_array(msi_irqs,
+ sizeof(*msi_data->msi_virqs),
+ GFP_KERNEL);
if (!msi_data->msi_virqs)
return -ENOMEM;
--
2.9.3
[PATCH 1/5] powerpc-mpic: Use kmalloc_array() in mpic_init()
From: Markus Elfring Date: Mon, 29 Aug 2016 11:00:11 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- arch/powerpc/sysdev/mpic.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c index 7de45b2..5e79c0d24 100644 --- a/arch/powerpc/sysdev/mpic.c +++ b/arch/powerpc/sysdev/mpic.c @@ -1641,8 +1641,9 @@ void __init mpic_init(struct mpic *mpic) #ifdef CONFIG_PM /* allocate memory to save mpic state */ - mpic->save_data = kmalloc(mpic->num_sources * sizeof(*mpic->save_data), - GFP_KERNEL); + mpic->save_data = kmalloc_array(mpic->num_sources, + sizeof(*mpic->save_data), + GFP_KERNEL); BUG_ON(mpic->save_data == NULL); #endif -- 2.9.3
[PATCH 0/5] PowerPC: Fine-tuning for three function implementations
From: Markus Elfring Date: Mon, 29 Aug 2016 11:44:22 +0200 Some update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use kmalloc_array() in mpic_init() Use kmalloc_array() in ppc4xx_setup_msi_irqs() Use kmalloc_array() in hsta_msi_probe() Rename jump labels in hsta_msi_probe() Move three assignments in hsta_msi_probe() arch/powerpc/sysdev/mpic.c| 5 +++-- arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 26 +- arch/powerpc/sysdev/ppc4xx_msi.c | 4 +++- 3 files changed, 19 insertions(+), 16 deletions(-) -- 2.9.3
[PATCH 0/5] PowerPC: Fine-tuning for three function implementations
From: Markus Elfring Date: Mon, 29 Aug 2016 11:44:22 +0200 Some update suggestions were taken into account from static source code analysis. Markus Elfring (5): Use kmalloc_array() in mpic_init() Use kmalloc_array() in ppc4xx_setup_msi_irqs() Use kmalloc_array() in hsta_msi_probe() Rename jump labels in hsta_msi_probe() Move three assignments in hsta_msi_probe() arch/powerpc/sysdev/mpic.c| 5 +++-- arch/powerpc/sysdev/ppc4xx_hsta_msi.c | 26 +- arch/powerpc/sysdev/ppc4xx_msi.c | 4 +++- 3 files changed, 19 insertions(+), 16 deletions(-) -- 2.9.3
Re: [PATCH 07/34] mm, vmscan: make kswapd reclaim in terms of nodes
> Patch "mm: vmscan: Begin reclaiming pages on a per-node basis" started > thinking of reclaim in terms of nodes but kswapd is still zone-centric. This > patch gets rid of many of the node-based versus zone-based decisions. > > o A node is considered balanced when any eligible lower zone is balanced. > This eliminates one class of age-inversion problem because we avoid > reclaiming a newer page just because it's in the wrong zone > o pgdat_balanced disappears because we now only care about one zone being > balanced. > o Some anomalies related to writeback and congestion tracking being based on > zones disappear. > o kswapd no longer has to take care to reclaim zones in the reverse order > that the page allocator uses. > o Most importantly of all, reclaim from node 0 with multiple zones will > have similar aging and reclaiming characteristics as every > other node. > > Signed-off-by: Mel Gorman > Acked-by: Johannes Weiner > Acked-by: Vlastimil Babka This patch seems to hurt FA_DUMP functionality. This behaviour is not seen on v4.7 but only after this patch. So when a kernel on a multinode machine with memblock_reserve() such that most of the nodes have zero available memory, kswapd seems to be consuming 100% of the time. This is independent of CONFIG_DEFERRED_STRUCT_PAGE, i.e this problem is seen even with parallel page struct initialization disabled. top - 13:48:52 up 1:07, 3 users, load average: 15.25, 15.32, 21.18 Tasks: 11080 total, 16 running, 11064 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 2.7 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 15929941+total, 8637824 used, 15843563+free, 2304 buffers KiB Swap: 91898816 total,0 used, 91898816 free. 1381312 cached Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 10824 root 20 0 0 0 0 R 100.000 0.000 65:30.76 kswapd2 10837 root 20 0 0 0 0 R 100.000 0.000 65:31.17 kswapd15 10823 root 20 0 0 0 0 R 97.059 0.000 65:30.85 kswapd1 10825 root 20 0 0 0 0 R 97.059 0.000 65:31.10 kswapd3 10826 root 20 0 0 0 0 R 97.059 0.000 65:31.18 kswapd4 10827 root 20 0 0 0 0 R 97.059 0.000 65:31.08 kswapd5 10828 root 20 0 0 0 0 R 97.059 0.000 65:30.91 kswapd6 10829 root 20 0 0 0 0 R 97.059 0.000 65:31.17 kswapd7 10830 root 20 0 0 0 0 R 97.059 0.000 65:31.17 kswapd8 10831 root 20 0 0 0 0 R 97.059 0.000 65:31.18 kswapd9 10832 root 20 0 0 0 0 R 97.059 0.000 65:31.12 kswapd10 10833 root 20 0 0 0 0 R 97.059 0.000 65:31.19 kswapd11 10834 root 20 0 0 0 0 R 97.059 0.000 65:31.13 kswapd12 10835 root 20 0 0 0 0 R 97.059 0.000 65:31.09 kswapd13 10836 root 20 0 0 0 0 R 97.059 0.000 65:31.18 kswapd14 277155 srikar20 0 16960 13760 3264 R 52.941 0.001 0:00.37 top top - 13:48:55 up 1:07, 3 users, load average: 15.23, 15.32, 21.15 Tasks: 11080 total, 16 running, 11064 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 1.0 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 15929941+total, 8637824 used, 15843563+free, 2304 buffers KiB Swap: 91898816 total,0 used, 91898816 free. 1381312 cached Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 10836 root 20 0 0 0 0 R 100.000 0.000 65:33.39 kswapd14 10823 root 20 0 0 0 0 R 100.000 0.000 65:33.05 kswapd1 10824 root 20 0 0 0 0 R 100.000 0.000 65:32.96 kswapd2 10825 root 20 0 0 0 0 R 100.000 0.000 65:33.30 kswapd3 10826 root 20 0 0 0 0 R 100.000 0.000 65:33.38 kswapd4 10827 root 20 0 0 0 0 R 100.000 0.000 65:33.28 kswapd5 10828 root 20 0 0 0 0 R 100.000 0.000 65:33.11 kswapd6 10829 root 20 0 0 0 0 R 100.000 0.000 65:33.37 kswapd7 10830 root 20 0 0 0 0 R 100.000 0.000 65:33.37 kswapd8 10831 root 20 0 0 0 0 R 100.000 0.000 65:33.38 kswapd9 10832 root 20 0 0 0 0 R 100.000 0.000 65:33.32 kswapd10 10833 root 20 0 0 0 0 R 100.000 0.000 65:33.39 kswapd11 10834 root 20 0 0 0 0 R 100.000 0.000 65:33.33 kswapd12 10835 root 20 0 0 0 0 R 100.000 0.000 65:33.29 kswapd13 10837 root 20 0 0 0 0 R 100.000 0.000 65:33.37 kswapd15 277155 srikar20 0 17536 14912 3264 R9.091 0.001 0:00.57 top 1092 root rt 0
