* [PATCH v06 5/5] migration/memory: Support 'ibm,dynamic-memory-v2'
From: Michael Bringmann @ 2018-10-15 19:55 UTC (permalink / raw)
Cc: Thomas Falcon, Michael Bringmann, Juliet Kim, Tyrel Datwyler,
Nathan Fontenot, linuxppc-dev
In-Reply-To: <20181015194806.5705.95242.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
migration/memory: This patch adds recognition for changes to the
associativity of memory blocks described by 'ibm,dynamic-memory-v2'.
If the associativity of an LMB has changed, it should be readded to
the system in order to update local and general kernel data structures.
This patch builds upon previous enhancements that scan the device-tree
"ibm,dynamic-memory" properties using the base LMB array, and a copy
derived from the updated properties.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index dc2aa34..8c08eb2 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -1184,7 +1184,8 @@ static int pseries_memory_notifier(struct notifier_block *nb,
err = pseries_remove_mem_node(rd->dn);
break;
case OF_RECONFIG_UPDATE_PROPERTY:
- if (!strcmp(rd->prop->name, "ibm,dynamic-memory")) {
+ if (!strcmp(rd->prop->name, "ibm,dynamic-memory") ||
+ !strcmp(rd->prop->name, "ibm,dynamic-memory-v2")) {
struct drmem_lmb_info *dinfo =
drmem_lmbs_init(rd->prop);
if (!dinfo)
^ permalink raw reply related
* [PATCH v06 2/5] powerpc/drmem: Add internal_flags feature
From: Michael Bringmann @ 2018-10-15 19:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Falcon, Michael Bringmann, Juliet Kim, Tyrel Datwyler,
Nathan Fontenot
In-Reply-To: <20181015194723.5705.51193.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
powerpc/drmem: Add internal_flags field to each LMB to allow
marking of kernel software-specific operations that need not
be exported to other users. For instance, if information about
selected LMBs needs to be maintained for subsequent passes
through the system, it can be encoded into the LMB array itself
without requiring the allocation and maintainance of additional
data structures.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
---
Changes in v04:
-- Add another initialization of 'lmb->internal_flags' to
init_drmem_v2_lmbs.
---
arch/powerpc/include/asm/drmem.h | 18 ++++++++++++++++++
arch/powerpc/mm/drmem.c | 3 +++
2 files changed, 21 insertions(+)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index cfe8598..dbb3e6c 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -17,6 +17,7 @@ struct drmem_lmb {
u32 drc_index;
u32 aa_index;
u32 flags;
+ u32 internal_flags;
};
struct drmem_lmb_info {
@@ -94,6 +95,23 @@ static inline bool drmem_lmb_reserved(struct drmem_lmb *lmb)
return lmb->flags & DRMEM_LMB_RESERVED;
}
+#define DRMEM_LMBINT_UPDATE 0x00000001
+
+static inline void drmem_mark_lmb_update(struct drmem_lmb *lmb)
+{
+ lmb->internal_flags |= DRMEM_LMBINT_UPDATE;
+}
+
+static inline void drmem_remove_lmb_update(struct drmem_lmb *lmb)
+{
+ lmb->internal_flags &= ~DRMEM_LMBINT_UPDATE;
+}
+
+static inline bool drmem_lmb_update(struct drmem_lmb *lmb)
+{
+ return lmb->internal_flags & DRMEM_LMBINT_UPDATE;
+}
+
u64 drmem_lmb_memory_max(void);
void __init walk_drmem_lmbs(struct device_node *dn,
void (*func)(struct drmem_lmb *, const __be32 **));
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index ded9dbf..f199fe5 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -207,6 +207,7 @@ static void read_drconf_v1_cell(struct drmem_lmb *lmb,
lmb->aa_index = of_read_number(p++, 1);
lmb->flags = of_read_number(p++, 1);
+ lmb->internal_flags = 0;
*prop = p;
}
@@ -265,6 +266,7 @@ static void __walk_drmem_v2_lmbs(const __be32 *prop, const __be32 *usm,
lmb.aa_index = dr_cell.aa_index;
lmb.flags = dr_cell.flags;
+ lmb.internal_flags = 0;
func(&lmb, &usm);
}
@@ -441,6 +443,7 @@ static void init_drmem_v2_lmbs(const __be32 *prop,
lmb->aa_index = dr_cell.aa_index;
lmb->flags = dr_cell.flags;
+ lmb->internal_flags = 0;
}
}
}
^ permalink raw reply related
* Re: linux-next: Tree for Oct 15
From: Stephen Rothwell @ 2018-10-15 20:12 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linux Kernel Mailing List, Linux-Next Mailing List, Rob Herring,
PowerPC
In-Reply-To: <20181015182637.GA16445@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 5216 bytes --]
Hi Guenter,
[Just cc'ing the PPC and devicetree folks]
On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> >
> > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
>
> Same here. Interestingly, this only affects little endian pseries
> boots; big endian works fine. I'll try to bisect later.
>
> ALl ppc qemu tests (including big endian pseries) also generate a warning.
>
> WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> IRQMASK: 1
> GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> Call Trace:
> [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
>
>
> sparc images crash, starting with next-20181009. Bisect with
> next-201810112 points to the merge of devicetree/for-next, though
> devicetree/for-next itself does not have the problem (bisect log
> attached below). The crash is in devicetree code.
>
> Crash logs:
> https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
>
> Guenter
>
> ---
> # bad: [774ea0551a2966c8fc29a6f675c3e28c5c6fa586] Add linux-next specific files for 20181012
> # good: [0238df646e6224016a45505d2c111a24669ebe21] Linux 4.19-rc7
> git bisect start 'HEAD' 'v4.19-rc7'
> # good: [dfbf78faefa3c26d94208398e62bf25ea798e7f2] Merge remote-tracking branch 'spi-nor/spi-nor/next'
> git bisect good dfbf78faefa3c26d94208398e62bf25ea798e7f2
> # bad: [3f296bb430327676912966c56d2f078f74e6b4ab] Merge remote-tracking branch 'tip/auto-latest'
> git bisect bad 3f296bb430327676912966c56d2f078f74e6b4ab
> # good: [efad9cbc89fbef3c4b3905e1c01a8191eae4c772] Merge remote-tracking branch 'sound/for-next'
> git bisect good efad9cbc89fbef3c4b3905e1c01a8191eae4c772
> # good: [7d12a265b24001fbff1ff260c2f6bd802224a7c0] Merge remote-tracking branch 'iommu/next'
> git bisect good 7d12a265b24001fbff1ff260c2f6bd802224a7c0
> # good: [4fc72c0ef3c1e792caf06d25ef68c7c871730e31] Merge branch 'ras/core'
> git bisect good 4fc72c0ef3c1e792caf06d25ef68c7c871730e31
> # good: [d74865bd3996c7a6f3e8ce6e626c1fe474e39494] Merge branch 'x86/mm'
> git bisect good d74865bd3996c7a6f3e8ce6e626c1fe474e39494
> # bad: [1b1ab6a98adab8a0436024b369305a978e365a13] Merge remote-tracking branch 'mailbox/mailbox-for-next'
> git bisect bad 1b1ab6a98adab8a0436024b369305a978e365a13
> # good: [389d0a8a7af8ff8bb6301382333c7e8f748d7cd6] Merge branch 'dt/cpu-type-rework' into dt/next
> git bisect good 389d0a8a7af8ff8bb6301382333c7e8f748d7cd6
> # good: [4355151de47c2b4bc72c026ee743bd9ed7f71ba3] Merge branch 'all-dtbs' into dt/next
> git bisect good 4355151de47c2b4bc72c026ee743bd9ed7f71ba3
> # good: [60d744213fd9433b10b23afafb694a44c8e96cb8] Merge remote-tracking branch 'vfio/next'
> git bisect good 60d744213fd9433b10b23afafb694a44c8e96cb8
> # good: [9f0a0a381c5db56e7922dbeea6831f27db58372f] mailbox: mediatek: Add check for possible failure of kzalloc
> git bisect good 9f0a0a381c5db56e7922dbeea6831f27db58372f
> # good: [157b4129ded8ba756ef17c058192e734889673e4] dt-bindings: arm: fsl: Move DCFG and SCFG bindings to their own docs
> git bisect good 157b4129ded8ba756ef17c058192e734889673e4
> # bad: [bed61948ea6c57bc73fb3ded9421c1bdd8cbe4d9] Merge remote-tracking branch 'devicetree/for-next'
> git bisect bad bed61948ea6c57bc73fb3ded9421c1bdd8cbe4d9
> # good: [d81cc4a8e47219fbe60d49446f04ed3e9c1657d9] dt-bindings: arm: zte: Move sysctrl bindings to their own doc
> git bisect good d81cc4a8e47219fbe60d49446f04ed3e9c1657d9
> # first bad commit: [bed61948ea6c57bc73fb3ded9421c1bdd8cbe4d9] Merge remote-tracking branch 'devicetree/for-next'
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 09/18] of: overlay: validate overlay properties #address-cells and #size-cells
From: Frank Rowand @ 2018-10-15 20:16 UTC (permalink / raw)
To: Alan Tull
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-fpga, Pantelis Antoniou, linux-kernel, Rob Herring,
Moritz Fischer, Paul Mackerras, linuxppc-dev
In-Reply-To: <CANk1AXQNkYDA9hRCMR_MkOJiobPjmYoJN8Gv+3YN9ReV+q5XEw@mail.gmail.com>
On 10/15/18 12:01, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM <frowand.list@gmail.com> wrote:
>>
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> If overlay properties #address-cells or #size-cells are already in
>> the live devicetree for any given node, then the values in the
>> overlay must match the values in the live tree.
>>
>> If the properties are already in the live tree then there is no
>> need to create a changeset entry to add them since they must
>> have the same value. This reduces the memory used by the
>> changeset and eliminates a possible memory leak. This is
>> verified by 12 fewer warnings during the devicetree unittest,
>> as the possible memory leak warnings about #address-cells and
>>
>> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
>> ---
>> drivers/of/overlay.c | 38 +++++++++++++++++++++++++++++++++++---
>> 1 file changed, 35 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index 272a0d1a5e18..ee66651db553 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -287,7 +287,12 @@ static struct property *dup_and_fixup_symbol_prop(
>> * @target may be either in the live devicetree or in a new subtree that
>> * is contained in the changeset.
>> *
>> - * Some special properties are not updated (no error returned).
>> + * Some special properties are not added or updated (no error returned):
>> + * "name", "phandle", "linux,phandle".
>> + *
>> + * Properties "#address-cells" and "#size-cells" are not updated if they
>> + * are already in the live tree, but if present in the live tree, the values
>> + * in the overlay must match the values in the live tree.
>> *
>> * Update of property in symbols node is not allowed.
>> *
>> @@ -300,6 +305,7 @@ static int add_changeset_property(struct overlay_changeset *ovcs,
>> {
>> struct property *new_prop = NULL, *prop;
>> int ret = 0;
>> + bool check_for_non_overlay_node = false;
>>
>> if (!of_prop_cmp(overlay_prop->name, "name") ||
>> !of_prop_cmp(overlay_prop->name, "phandle") ||
>> @@ -322,13 +328,39 @@ static int add_changeset_property(struct overlay_changeset *ovcs,
>> if (!new_prop)
>> return -ENOMEM;
>>
>> - if (!prop)
>> + if (!prop) {
>> +
>> + check_for_non_overlay_node = true;
>> ret = of_changeset_add_property(&ovcs->cset, target->np,
>> new_prop);
>> - else
>> +
>> + } else if (!of_prop_cmp(prop->name, "#address-cells")) {
>> +
>
> Hi Frank,
>
> If we get these ERROR messages, I suggest that this function should
> return an error so the overlay will be rejected.
>
>> + if (prop->length != 4 || new_prop->length != 4 ||
>> + *(u32 *)prop->value != *(u32 *)new_prop->value)
>
> *(u32 *)prop->value != *(u32 *)new_prop->value) {
>
>> + pr_err("ERROR: overlay and/or live tree #address-cells invalid in node %pOF\n",
>> + target->np);
>
> ret = -EINVAL;
> }
>
> Otherwise there is an ERROR message, but it continues trying to apply
> the invalid overlay anyway and I get an oops. By adding the ret =
> -EINVAL, the overlay gets rejected and the oops is avoided.
Yes, that sounds good.
>> +
>> + } else if (!of_prop_cmp(prop->name, "#size-cells")) {
>> +
>> + if (prop->length != 4 || new_prop->length != 4 ||
>> + *(u32 *)prop->value != *(u32 *)new_prop->value)
>> + pr_err("ERROR: overlay and/or live tree #size-cells invalid in node %pOF\n",
>> + target->np);
>
> Add the ret = -EINVAL here also. This give me the following (if my
> overlay changes #address-cells):
Yes.
> [ 21.167551] OF: overlay: ERROR: overlay and/or live tree
> #address-cells invalid in node /soc/base_fpga_region
> [ 21.177442] OF: overlay: add_changeset_property ret=-22
> [ 21.182656] create_overlay: Failed to create overlay (err=-22)
>
> Also, I wonder if the ERROR message could be more direct. Currently
> it says the #address-cells property is invalid but that doesn't say
> anything about why it's invalid. How about something like:
>
> OF: overlay: ERROR: changing #address-cells not allowed (/soc/base_fpga_region)
That sounds like a more useful message, maybe a slight change
s/changing #address-cells/changing value of #address-cells/
> The 'OF: overlay' part still makes it clear it's overlay related. The
> rest of it makes it clear *why* it's invalid. This ERROR will be a
> surprise for people who have been using overlays, so that could be
> helpful to light the way a bit.
>
> Alan
>
>> +
>> + } else {
>> +
>> + check_for_non_overlay_node = true;
>> ret = of_changeset_update_property(&ovcs->cset, target->np,
>> new_prop);
>>
>> + }
>> +
>> + if (check_for_non_overlay_node &&
>> + !of_node_check_flag(target->np, OF_OVERLAY))
>> + pr_err("WARNING: %s(), memory leak will occur if overlay removed. Property: %pOF/%s\n",
>> + __func__, target->np, new_prop->name);
>> +
>> if (ret) {
>> kfree(new_prop->name);
>> kfree(new_prop->value);
>> --
>> Frank Rowand <frank.rowand@sony.com>
>>
>
^ permalink raw reply
* Re: [PATCH v3 00/18] of: overlay: validation checks, subsequent fixes
From: Frank Rowand @ 2018-10-15 20:23 UTC (permalink / raw)
To: Alan Tull
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-fpga, Pantelis Antoniou, linux-kernel, Rob Herring,
Moritz Fischer, Paul Mackerras, linuxppc-dev
In-Reply-To: <CANk1AXTmY7v03m7NNZHVtzyU1Mwm0GYtOJQzmObFLASs=PEfLA@mail.gmail.com>
On 10/15/18 12:21, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM <frowand.list@gmail.com> wrote:
>>
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> Add checks to (1) overlay apply process and (2) memory freeing
>> triggered by overlay release. The checks are intended to detect
>> possible memory leaks and invalid overlays.
>>
>> The checks revealed bugs in existing code. Fixed the bugs.
>>
>> While fixing bugs, noted other issues, which are fixed in
>> separate patches.
>>
>> ***** Powerpc folks: I was not able to test the patches that
>> ***** directly impact Powerpc systems that use dynamic
>> ***** devicetree. Please review that code carefully and
>> ***** test. The specific patches are: 03/16, 04/16, 07/16
>>
>> FPGA folks:
>>
>> I made the validation checks that should result in an
>> invalid live devicetree report "ERROR" and cause the overlay apply
>> to fail.
>>
>> I made the memory leak validation tests report "WARNING" and allow
>> the overlay apply to complete successfully. Please let me know
>> if you encounter the warnings. There are at least two paths
>> forward to deal with the cases that trigger the warning: (1) change
>> the warning to an error and fail the overlay apply, or (2) find a
>> way to detect the potential memory leaks and free the memory
>> appropriately.
>
> I reran my FPGA testing. The strings are fixed, no longer NULL. I
Thanks for the further testing!
> have functionality back, my test passes now. I'm seeing the intended
> warnings about any properties added to existing nodes. That includes
> warnings about added symbols. Below is a simplified part to show some
> of what I'm seeing.
>
> By the way my testing is all using Pantelis' DT overlay configfs interface.
>
> root@arria10:~# ./apply-static-region.sh
>
> Applying dtbo: socfpga_arria10_socdk_sdmmc_ghrd_ovl_ext_cfg.dtb
>
> [ 1821.088640] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /soc/base_fpga_region/ranges
> [ 1821.103307] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /soc/base_fpga_region/external-fpga-config
> [ 1821.117359] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /soc/base_fpga_region/clocks
> [ 1821.130130] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /soc/base_fpga_region/clock-names
> [ 1821.143449] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property: /__symbols__/clk_0
> [ 1821.155357] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property: /__symbols__/ILC
> [ 1821.167074] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /__symbols__/freeze_controller_0
> [ 1821.180171] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property:
> /__symbols__/sysid_qsys_0
> [ 1821.192662] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property: /__symbols__/led_pio
> [ 1821.204720] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property: /__symbols__/button_pio
> [ 1821.217034] OF: overlay: WARNING: add_changeset_property(), memory
> leak will occur if overlay removed. Property: /__symbols__/dipsw_pio
> [ 1821.231977] of-fpga-region soc:base_fpga_region:fpga_pr_region0:
> FPGA Region probed
> [ 1821.240144] altera_freeze_br ff200450.freeze_controller: fpga
> bridge [freeze] registered
>
> root@arria10:~# ./apply-static-region.sh root@arria10:~# rmdir
> /sys/kernel/config/device-tree/overlays/1-socfpga_arria10_socdk_sdmmc_ghrd_ovl_ext_cfg.dtb
>
> [ 1823.805564] OF: ERROR: memory leak - destroy cset entry: attach
> overlay node /soc/base_fpga_region/clk_0 with refcount 2
That is indicating that an unbalanced of_node_get() / of_node_put()
exists for that node. I'll have to update that message to be more
explicit about that.
-Frank
>
> Alan
>
>
> Alan
>
>
>
>>
>> ALL people:
>>
>> The validations do _not_ address another major concern I have with
>> releasing overlays, which is use after free errors.
>>
>> Changes since v2:
>>
>> - 13/18: Use continue to reduce indentation in find_dup_cset_node_entry()
>> and find_dup_cset_prop()
>>
>> Changes since v1:
>>
>> - move patch 16/16 to 17/18
>> - move patch 15/16 to 18/18
>> - new patch 15/18
>> - new patch 16/18
>>
>> - 05/18: add_changeset_node() header comment: incorrect comment for @target
>>
>> - 18/18: add same fix for of_parse_phandle_with_args()
>> - 18/18: add same fix for of_parse_phandle_with_args_map()
>>
>> Frank Rowand (18):
>> of: overlay: add tests to validate kfrees from overlay removal
>> of: overlay: add missing of_node_put() after add new node to changeset
>> of: overlay: add missing of_node_get() in __of_attach_node_sysfs
>> powerpc/pseries: add of_node_put() in dlpar_detach_node()
>> of: overlay: use prop add changeset entry for property in new nodes
>> of: overlay: do not duplicate properties from overlay for new nodes
>> of: dynamic: change type of of_{at,de}tach_node() to void
>> of: overlay: reorder fields in struct fragment
>> of: overlay: validate overlay properties #address-cells and
>> #size-cells
>> of: overlay: make all pr_debug() and pr_err() messages unique
>> of: overlay: test case of two fragments adding same node
>> of: overlay: check prevents multiple fragments add or delete same node
>> of: overlay: check prevents multiple fragments touching same property
>> of: unittest: remove unused of_unittest_apply_overlay() argument
>> of: overlay: set node fields from properties when add new overlay node
>> of: unittest: allow base devicetree to have symbol metadata
>> of: unittest: find overlays[] entry by name instead of index
>> of: unittest: initialize args before calling of_*parse_*()
>>
>> arch/powerpc/platforms/pseries/dlpar.c | 15 +-
>> arch/powerpc/platforms/pseries/reconfig.c | 6 +-
>> drivers/of/dynamic.c | 68 +++--
>> drivers/of/kobj.c | 4 +-
>> drivers/of/overlay.c | 298 ++++++++++++++++-----
>> drivers/of/unittest-data/Makefile | 2 +
>> .../of/unittest-data/overlay_bad_add_dup_node.dts | 28 ++
>> .../of/unittest-data/overlay_bad_add_dup_prop.dts | 24 ++
>> drivers/of/unittest-data/overlay_base.dts | 1 +
>> drivers/of/unittest.c | 96 +++++--
>> include/linux/of.h | 19 +-
>> 11 files changed, 439 insertions(+), 122 deletions(-)
>> create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_node.dts
>> create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_prop.dts
>>
>> --
>> Frank Rowand <frank.rowand@sony.com>
>>
>
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Stephen Rothwell @ 2018-10-15 20:24 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mike Rapoport, Linux Kernel Mailing List, Linux-Next Mailing List,
Rob Herring, Andrew Morton, PowerPC
In-Reply-To: <20181016071240.3f62816d@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
Hi all,
On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> >
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
That is:
static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
phys_addr_t align, phys_addr_t start,
phys_addr_t end, int nid,
enum memblock_flags flags)
{
if (WARN_ON_ONCE(!align))
align = SMP_CACHE_BYTES;
Looks like patch
"memblock: stop using implicit alignment to SMP_CACHE_BYTES"
missed some places ...
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > IRQMASK: 1
> > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > Call Trace:
> > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Stephen Rothwell @ 2018-10-15 20:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linux Kernel Mailing List, Mike Rapoport, Linux-Next Mailing List,
Andrew Morton, PowerPC
In-Reply-To: <20181015193914.GA9881@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]
Hi Guenter,
[Again, just cc'ing the PPC folks]
On Mon, 15 Oct 2018 12:39:14 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20181012:
> >
> > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> >
>
> Bisect log:
>
> # bad: [774ea0551a2966c8fc29a6f675c3e28c5c6fa586] Add linux-next specific files for 20181012
> # good: [0238df646e6224016a45505d2c111a24669ebe21] Linux 4.19-rc7
> git bisect start 'HEAD' 'v4.19-rc7'
> # good: [dfbf78faefa3c26d94208398e62bf25ea798e7f2] Merge remote-tracking branch 'spi-nor/spi-nor/next'
> git bisect good dfbf78faefa3c26d94208398e62bf25ea798e7f2
> # good: [3f296bb430327676912966c56d2f078f74e6b4ab] Merge remote-tracking branch 'tip/auto-latest'
> git bisect good 3f296bb430327676912966c56d2f078f74e6b4ab
> # good: [056ff0c45d1780f7bac1b54bd4160647efc500ad] Merge remote-tracking branch 'staging/staging-next'
> git bisect good 056ff0c45d1780f7bac1b54bd4160647efc500ad
> # good: [d7946b50c21a7d88af6c8e88d976ba3dfca651cc] Merge remote-tracking branch 'pinctrl/for-next'
> git bisect good d7946b50c21a7d88af6c8e88d976ba3dfca651cc
> # good: [72b5ca3121d5352fbb8fe3e1abaa86748205c0cb] Merge remote-tracking branch 'xarray/xarray'
> git bisect good 72b5ca3121d5352fbb8fe3e1abaa86748205c0cb
> # good: [e3895cf23a25da6dea2c8e986d4f6c24fafe5448] hugetlb: introduce generic version of prepare_hugepage_range
> git bisect good e3895cf23a25da6dea2c8e986d4f6c24fafe5448
> # good: [627f8833ac26e66d4b50676a0251499474bb4ee4] reiserfs: propagate errors from fill_with_dentries() properly
> git bisect good 627f8833ac26e66d4b50676a0251499474bb4ee4
> # good: [e38910adf47ba1d0b5a5a573cc26bde1ec533147] memblock: replace alloc_bootmem_pages_node with memblock_alloc_node
> git bisect good e38910adf47ba1d0b5a5a573cc26bde1ec533147
> # bad: [f89bdd2c52666d9da4bf4ef3a97a7188586ba0fb] dma-direct: fix up for the removal of linux/bootmem.h
> git bisect bad f89bdd2c52666d9da4bf4ef3a97a7188586ba0fb
> # good: [3108d998dfc36eb7f6b7f2917fc561258f742094] mm: nobootmem: remove bootmem allocation APIs
> git bisect good 3108d998dfc36eb7f6b7f2917fc561258f742094
> # good: [1f94dacb1d0ed0d1068b89ad867a198d3eca7bf2] memblock: rename __free_pages_bootmem to memblock_free_pages
> git bisect good 1f94dacb1d0ed0d1068b89ad867a198d3eca7bf2
> # good: [c3954ade0c1b499ae587f3edb813876216212836] memblock: replace BOOTMEM_ALLOC_* with MEMBLOCK variants
> git bisect good c3954ade0c1b499ae587f3edb813876216212836
> # bad: [cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6] mm: remove include/linux/bootmem.h
> git bisect bad cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6
> # first bad commit: [cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6] mm: remove include/linux/bootmem.h
>
> Reverting this patch together with its fix-up "powerpc: fix up for removal of
> linux/bootmem.h" fixes the problem. This also fixes the traceback seen with all
> other ppc64 images.
>
> Guenter
Thanks for this ... though a strange result as those patches were in
next-20181012 as well, so I wonder what else changed.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Rob Herring @ 2018-10-15 20:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel@vger.kernel.org, linux-next, linuxppc-dev,
Guenter Roeck
In-Reply-To: <20181016071240.3f62816d@canb.auug.org.au>
On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Guenter,
>
> [Just cc'ing the PPC and devicetree folks]
>
> On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > >
> > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> >
> > Same here. Interestingly, this only affects little endian pseries
> > boots; big endian works fine. I'll try to bisect later.
> >
> > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> >
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > IRQMASK: 1
> > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > Call Trace:
> > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> >
> >
> > sparc images crash, starting with next-20181009. Bisect with
> > next-201810112 points to the merge of devicetree/for-next, though
> > devicetree/for-next itself does not have the problem (bisect log
> > attached below). The crash is in devicetree code.
> >
> > Crash logs:
> > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
The sparc crash appears to be related to changes I made. Looking into it.
Rob
^ permalink raw reply
* Re: [PATCH v3 00/18] of: overlay: validation checks, subsequent fixes
From: Alan Tull @ 2018-10-15 20:47 UTC (permalink / raw)
To: Frank Rowand
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-fpga, Pantelis Antoniou, linux-kernel, Rob Herring,
Moritz Fischer, Paul Mackerras, linuxppc-dev
In-Reply-To: <34775737-d82b-b766-16d7-ac2de3231948@gmail.com>
On Mon, Oct 15, 2018 at 3:24 PM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 10/15/18 12:21, Alan Tull wrote:
> > On Sun, Oct 14, 2018 at 7:26 PM <frowand.list@gmail.com> wrote:
> >>
> >> From: Frank Rowand <frank.rowand@sony.com>
> >>
> >> Add checks to (1) overlay apply process and (2) memory freeing
> >> triggered by overlay release. The checks are intended to detect
> >> possible memory leaks and invalid overlays.
> >>
> >> The checks revealed bugs in existing code. Fixed the bugs.
> >>
> >> While fixing bugs, noted other issues, which are fixed in
> >> separate patches.
> >>
> >> ***** Powerpc folks: I was not able to test the patches that
> >> ***** directly impact Powerpc systems that use dynamic
> >> ***** devicetree. Please review that code carefully and
> >> ***** test. The specific patches are: 03/16, 04/16, 07/16
> >>
> >> FPGA folks:
> >>
> >> I made the validation checks that should result in an
> >> invalid live devicetree report "ERROR" and cause the overlay apply
> >> to fail.
> >>
> >> I made the memory leak validation tests report "WARNING" and allow
> >> the overlay apply to complete successfully. Please let me know
> >> if you encounter the warnings. There are at least two paths
> >> forward to deal with the cases that trigger the warning: (1) change
> >> the warning to an error and fail the overlay apply, or (2) find a
> >> way to detect the potential memory leaks and free the memory
> >> appropriately.
> >
> > I reran my FPGA testing. The strings are fixed, no longer NULL. I
>
> Thanks for the further testing!
>
>
> > have functionality back, my test passes now. I'm seeing the intended
> > warnings about any properties added to existing nodes. That includes
> > warnings about added symbols. Below is a simplified part to show some
> > of what I'm seeing.
> >
> > By the way my testing is all using Pantelis' DT overlay configfs interface.
> >
> > root@arria10:~# ./apply-static-region.sh
> >
> > Applying dtbo: socfpga_arria10_socdk_sdmmc_ghrd_ovl_ext_cfg.dtb
> >
> > [ 1821.088640] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /soc/base_fpga_region/ranges
> > [ 1821.103307] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /soc/base_fpga_region/external-fpga-config
> > [ 1821.117359] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /soc/base_fpga_region/clocks
> > [ 1821.130130] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /soc/base_fpga_region/clock-names
> > [ 1821.143449] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property: /__symbols__/clk_0
> > [ 1821.155357] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property: /__symbols__/ILC
> > [ 1821.167074] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /__symbols__/freeze_controller_0
> > [ 1821.180171] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property:
> > /__symbols__/sysid_qsys_0
> > [ 1821.192662] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property: /__symbols__/led_pio
> > [ 1821.204720] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property: /__symbols__/button_pio
> > [ 1821.217034] OF: overlay: WARNING: add_changeset_property(), memory
> > leak will occur if overlay removed. Property: /__symbols__/dipsw_pio
> > [ 1821.231977] of-fpga-region soc:base_fpga_region:fpga_pr_region0:
> > FPGA Region probed
> > [ 1821.240144] altera_freeze_br ff200450.freeze_controller: fpga
> > bridge [freeze] registered
> >
> > root@arria10:~# ./apply-static-region.sh root@arria10:~# rmdir
> > /sys/kernel/config/device-tree/overlays/1-socfpga_arria10_socdk_sdmmc_ghrd_ovl_ext_cfg.dtb
> >
>
>
> > [ 1823.805564] OF: ERROR: memory leak - destroy cset entry: attach
> > overlay node /soc/base_fpga_region/clk_0 with refcount 2
>
> That is indicating that an unbalanced of_node_get() / of_node_put()
> exists for that node. I'll have to update that message to be more
> explicit about that.
Yes, that sounds good
>
> -Frank
>
> >
> > Alan
> >
> >
> > Alan
> >
> >
> >
> >>
> >> ALL people:
> >>
> >> The validations do _not_ address another major concern I have with
> >> releasing overlays, which is use after free errors.
> >>
> >> Changes since v2:
> >>
> >> - 13/18: Use continue to reduce indentation in find_dup_cset_node_entry()
> >> and find_dup_cset_prop()
> >>
> >> Changes since v1:
> >>
> >> - move patch 16/16 to 17/18
> >> - move patch 15/16 to 18/18
> >> - new patch 15/18
> >> - new patch 16/18
> >>
> >> - 05/18: add_changeset_node() header comment: incorrect comment for @target
> >>
> >> - 18/18: add same fix for of_parse_phandle_with_args()
> >> - 18/18: add same fix for of_parse_phandle_with_args_map()
> >>
> >> Frank Rowand (18):
> >> of: overlay: add tests to validate kfrees from overlay removal
> >> of: overlay: add missing of_node_put() after add new node to changeset
> >> of: overlay: add missing of_node_get() in __of_attach_node_sysfs
> >> powerpc/pseries: add of_node_put() in dlpar_detach_node()
> >> of: overlay: use prop add changeset entry for property in new nodes
> >> of: overlay: do not duplicate properties from overlay for new nodes
> >> of: dynamic: change type of of_{at,de}tach_node() to void
> >> of: overlay: reorder fields in struct fragment
> >> of: overlay: validate overlay properties #address-cells and
> >> #size-cells
> >> of: overlay: make all pr_debug() and pr_err() messages unique
> >> of: overlay: test case of two fragments adding same node
> >> of: overlay: check prevents multiple fragments add or delete same node
> >> of: overlay: check prevents multiple fragments touching same property
> >> of: unittest: remove unused of_unittest_apply_overlay() argument
> >> of: overlay: set node fields from properties when add new overlay node
> >> of: unittest: allow base devicetree to have symbol metadata
> >> of: unittest: find overlays[] entry by name instead of index
> >> of: unittest: initialize args before calling of_*parse_*()
> >>
> >> arch/powerpc/platforms/pseries/dlpar.c | 15 +-
> >> arch/powerpc/platforms/pseries/reconfig.c | 6 +-
> >> drivers/of/dynamic.c | 68 +++--
> >> drivers/of/kobj.c | 4 +-
> >> drivers/of/overlay.c | 298 ++++++++++++++++-----
> >> drivers/of/unittest-data/Makefile | 2 +
> >> .../of/unittest-data/overlay_bad_add_dup_node.dts | 28 ++
> >> .../of/unittest-data/overlay_bad_add_dup_prop.dts | 24 ++
> >> drivers/of/unittest-data/overlay_base.dts | 1 +
> >> drivers/of/unittest.c | 96 +++++--
> >> include/linux/of.h | 19 +-
> >> 11 files changed, 439 insertions(+), 122 deletions(-)
> >> create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_node.dts
> >> create mode 100644 drivers/of/unittest-data/overlay_bad_add_dup_prop.dts
> >>
> >> --
> >> Frank Rowand <frank.rowand@sony.com>
> >>
> >
>
^ permalink raw reply
* Re: [PATCH 1/8] aha152x: rename the PCMCIA define
From: Bjorn Helgaas @ 2018-10-15 20:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-scsi, linux-kbuild, linux-pci, linux-kernel,
Dominik Brodowski, Masahiro Yamada, Alexandre Bounine,
linuxppc-dev
In-Reply-To: <20181013151016.31674-2-hch@lst.de>
On Sat, Oct 13, 2018 at 05:10:09PM +0200, Christoph Hellwig wrote:
> We plan to enable building the pcmcia core and drivers, and the
> non-prefixed PCMCIA name clashes with some arch headers.
In the followup PCMCIA patch, you capitalized "PCMCIA core".
^ permalink raw reply
* Re: [PATCH 4/8] pci: consolidate PCI config entry in drivers/pci
From: Bjorn Helgaas @ 2018-10-15 20:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-scsi, linux-kbuild, linux-pci, linux-kernel,
Dominik Brodowski, Masahiro Yamada, Alexandre Bounine,
linuxppc-dev
In-Reply-To: <20181013151016.31674-5-hch@lst.de>
s/^pci: /PCI: / in subject
On Sat, Oct 13, 2018 at 05:10:12PM +0200, Christoph Hellwig wrote:
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAS_PCI symbol that indicates availability
> of PCI support and the handle the rest in drivers/pci.
>
> Note that for powerpc we now select HAS_PCI globally instead of the
> convoluted mess of conditional or or non-conditional support per board,
> similar to what we do e.g. on x86. For alpha PCI is selected for the
> non-jensen configs as it was the default before, and a lot of code does
> not compile without PCI enabled. On other architectures with limited
> PCI support that wasn't as complicated I've left the selection as-is.
Thanks for doing this. It's a great cleanup. I know you have a few
things you're cleaning up, but add my:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
when you do that.
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 21:18 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <CAL_Jsq+DAEEa6i9xb-9MMSxu-znc9tZLZwFRADqE+kcxQYXrTg@mail.gmail.com>
On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi Guenter,
> >
> > [Just cc'ing the PPC and devicetree folks]
> >
> > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > >
> > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > >
> > > Same here. Interestingly, this only affects little endian pseries
> > > boots; big endian works fine. I'll try to bisect later.
> > >
> > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > >
> > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > Modules linked in:
> > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > IRQMASK: 1
> > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > Call Trace:
> > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > >
> > >
> > > sparc images crash, starting with next-20181009. Bisect with
> > > next-201810112 points to the merge of devicetree/for-next, though
> > > devicetree/for-next itself does not have the problem (bisect log
> > > attached below). The crash is in devicetree code.
> > >
> > > Crash logs:
> > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
>
> The sparc crash appears to be related to changes I made. Looking into it.
>
Let me know if you need me to test anything or do some debugging.
Thanks,
Guenter
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 21:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Kernel Mailing List, Mike Rapoport, Linux-Next Mailing List,
Andrew Morton, PowerPC
In-Reply-To: <20181016073359.3fa7bb32@canb.auug.org.au>
On Tue, Oct 16, 2018 at 07:33:59AM +1100, Stephen Rothwell wrote:
> Hi Guenter,
>
> [Again, just cc'ing the PPC folks]
>
> On Mon, 15 Oct 2018 12:39:14 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20181012:
> > >
> > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > >
> >
> > Bisect log:
> >
> > # bad: [774ea0551a2966c8fc29a6f675c3e28c5c6fa586] Add linux-next specific files for 20181012
> > # good: [0238df646e6224016a45505d2c111a24669ebe21] Linux 4.19-rc7
> > git bisect start 'HEAD' 'v4.19-rc7'
> > # good: [dfbf78faefa3c26d94208398e62bf25ea798e7f2] Merge remote-tracking branch 'spi-nor/spi-nor/next'
> > git bisect good dfbf78faefa3c26d94208398e62bf25ea798e7f2
> > # good: [3f296bb430327676912966c56d2f078f74e6b4ab] Merge remote-tracking branch 'tip/auto-latest'
> > git bisect good 3f296bb430327676912966c56d2f078f74e6b4ab
> > # good: [056ff0c45d1780f7bac1b54bd4160647efc500ad] Merge remote-tracking branch 'staging/staging-next'
> > git bisect good 056ff0c45d1780f7bac1b54bd4160647efc500ad
> > # good: [d7946b50c21a7d88af6c8e88d976ba3dfca651cc] Merge remote-tracking branch 'pinctrl/for-next'
> > git bisect good d7946b50c21a7d88af6c8e88d976ba3dfca651cc
> > # good: [72b5ca3121d5352fbb8fe3e1abaa86748205c0cb] Merge remote-tracking branch 'xarray/xarray'
> > git bisect good 72b5ca3121d5352fbb8fe3e1abaa86748205c0cb
> > # good: [e3895cf23a25da6dea2c8e986d4f6c24fafe5448] hugetlb: introduce generic version of prepare_hugepage_range
> > git bisect good e3895cf23a25da6dea2c8e986d4f6c24fafe5448
> > # good: [627f8833ac26e66d4b50676a0251499474bb4ee4] reiserfs: propagate errors from fill_with_dentries() properly
> > git bisect good 627f8833ac26e66d4b50676a0251499474bb4ee4
> > # good: [e38910adf47ba1d0b5a5a573cc26bde1ec533147] memblock: replace alloc_bootmem_pages_node with memblock_alloc_node
> > git bisect good e38910adf47ba1d0b5a5a573cc26bde1ec533147
> > # bad: [f89bdd2c52666d9da4bf4ef3a97a7188586ba0fb] dma-direct: fix up for the removal of linux/bootmem.h
> > git bisect bad f89bdd2c52666d9da4bf4ef3a97a7188586ba0fb
> > # good: [3108d998dfc36eb7f6b7f2917fc561258f742094] mm: nobootmem: remove bootmem allocation APIs
> > git bisect good 3108d998dfc36eb7f6b7f2917fc561258f742094
> > # good: [1f94dacb1d0ed0d1068b89ad867a198d3eca7bf2] memblock: rename __free_pages_bootmem to memblock_free_pages
> > git bisect good 1f94dacb1d0ed0d1068b89ad867a198d3eca7bf2
> > # good: [c3954ade0c1b499ae587f3edb813876216212836] memblock: replace BOOTMEM_ALLOC_* with MEMBLOCK variants
> > git bisect good c3954ade0c1b499ae587f3edb813876216212836
> > # bad: [cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6] mm: remove include/linux/bootmem.h
> > git bisect bad cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6
> > # first bad commit: [cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6] mm: remove include/linux/bootmem.h
> >
> > Reverting this patch together with its fix-up "powerpc: fix up for removal of
> > linux/bootmem.h" fixes the problem. This also fixes the traceback seen with all
> > other ppc64 images.
> >
> > Guenter
>
> Thanks for this ... though a strange result as those patches were in
> next-20181012 as well, so I wonder what else changed.
>
Quite simple - the bisect is wrong. For some reason I started with
next-20181012 (which was fine), not 20181015 (which is broken).
Repeating it now. Sorry for the confusion.
Guenter
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Rob Herring @ 2018-10-15 21:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <20181015211815.GA24993@roeck-us.net>
On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Guenter,
> > >
> > > [Just cc'ing the PPC and devicetree folks]
> > >
> > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > >
> > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > >
> > > > Same here. Interestingly, this only affects little endian pseries
> > > > boots; big endian works fine. I'll try to bisect later.
> > > >
> > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > >
> > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > Modules linked in:
> > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > IRQMASK: 1
> > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > Call Trace:
> > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > >
> > > >
> > > > sparc images crash, starting with next-20181009. Bisect with
> > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > devicetree/for-next itself does not have the problem (bisect log
> > > > attached below). The crash is in devicetree code.
> > > >
> > > > Crash logs:
> > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> >
> > The sparc crash appears to be related to changes I made. Looking into it.
> >
>
> Let me know if you need me to test anything or do some debugging.
Well, I'm not having any luck getting sparc qemu to work. Here's what
I'm trying with a sparc32_defconfig kernel:
$ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
256 -no-reboot
rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
free=0x000000000000057a, addr=0x0000000000000000)
qemu-system-sparc: rom check and register reset failed
Using zImage or image file didn't work any better.
Then I tried sticking the kernel in a disk image, but that didn't get
much farther.
Rob
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 22:10 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <CAL_JsqKXS0rmmwHgLRDy+6k=GYRt-nFJHJD1A+CkFCDEAEAKvg@mail.gmail.com>
On Mon, Oct 15, 2018 at 04:48:27PM -0500, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi Guenter,
> > > >
> > > > [Just cc'ing the PPC and devicetree folks]
> > > >
> > > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > > >
> > > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > > >
> > > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > > >
> > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > boots; big endian works fine. I'll try to bisect later.
> > > > >
> > > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > >
> > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > > Modules linked in:
> > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > > IRQMASK: 1
> > > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > Call Trace:
> > > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > > >
> > > > >
> > > > > sparc images crash, starting with next-20181009. Bisect with
> > > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > > devicetree/for-next itself does not have the problem (bisect log
> > > > > attached below). The crash is in devicetree code.
> > > > >
> > > > > Crash logs:
> > > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> > >
> > > The sparc crash appears to be related to changes I made. Looking into it.
> > >
> >
> > Let me know if you need me to test anything or do some debugging.
>
> Well, I'm not having any luck getting sparc qemu to work. Here's what
> I'm trying with a sparc32_defconfig kernel:
>
> $ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
> 256 -no-reboot
> rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
> free=0x000000000000057a, addr=0x0000000000000000)
> qemu-system-sparc: rom check and register reset failed
>
What is your qemu version ?
Guenter
> Using zImage or image file didn't work any better.
>
> Then I tried sticking the kernel in a disk image, but that didn't get
> much farther.
>
> Rob
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Rob Herring @ 2018-10-15 22:13 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <20181015221053.GA19822@roeck-us.net>
On Mon, Oct 15, 2018 at 5:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Mon, Oct 15, 2018 at 04:48:27PM -0500, Rob Herring wrote:
> > On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > > > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > Hi Guenter,
> > > > >
> > > > > [Just cc'ing the PPC and devicetree folks]
> > > > >
> > > > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > >
> > > > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > > > >
> > > > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > > > >
> > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > >
> > > > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > > >
> > > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > > > Modules linked in:
> > > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > > > IRQMASK: 1
> > > > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > Call Trace:
> > > > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > > > >
> > > > > >
> > > > > > sparc images crash, starting with next-20181009. Bisect with
> > > > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > > > devicetree/for-next itself does not have the problem (bisect log
> > > > > > attached below). The crash is in devicetree code.
> > > > > >
> > > > > > Crash logs:
> > > > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> > > >
> > > > The sparc crash appears to be related to changes I made. Looking into it.
> > > >
> > >
> > > Let me know if you need me to test anything or do some debugging.
> >
> > Well, I'm not having any luck getting sparc qemu to work. Here's what
> > I'm trying with a sparc32_defconfig kernel:
> >
> > $ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
> > 256 -no-reboot
> > rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
> > free=0x000000000000057a, addr=0x0000000000000000)
> > qemu-system-sparc: rom check and register reset failed
> >
>
> What is your qemu version ?
2.11 from ubuntu 18.04:
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5)
Rob
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Andrew Morton @ 2018-10-15 22:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mike Rapoport, Linux Kernel Mailing List, Linux-Next Mailing List,
Rob Herring, PowerPC, Guenter Roeck
In-Reply-To: <20181016072439.42613abd@canb.auug.org.au>
On Tue, 16 Oct 2018 07:24:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > >
> > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
>
> That is:
>
> static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size,
> phys_addr_t align, phys_addr_t start,
> phys_addr_t end, int nid,
> enum memblock_flags flags)
> {
> if (WARN_ON_ONCE(!align))
> align = SMP_CACHE_BYTES;
>
> Looks like patch
>
> "memblock: stop using implicit alignment to SMP_CACHE_BYTES"
>
> missed some places ...
To be expected, I guess. I'm pretty relaxed about this ;) Let's do
another sweep in a week or so, after which we'll have a couple of
months to mop up any leftovers.
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 22:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Kernel Mailing List, Mike Rapoport, Linux-Next Mailing List,
Andrew Morton, PowerPC
In-Reply-To: <20181016073359.3fa7bb32@canb.auug.org.au>
On Tue, Oct 16, 2018 at 07:33:59AM +1100, Stephen Rothwell wrote:
> Hi Guenter,
>
> [Again, just cc'ing the PPC folks]
>
> On Mon, 15 Oct 2018 12:39:14 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20181012:
> > >
> > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > >
> >
> > Bisect log:
> >
Trying again. Not very useful since some of the steps fail with compile errors.
The problem does seem to be related to the bootmem changes, though.
I might try again tonight if I find the time.
Guenter
# bad: [ca0591d03a2d373e0019ad357fbbee69c8272381] Add linux-next specific files for 20181015
# good: [0238df646e6224016a45505d2c111a24669ebe21] Linux 4.19-rc7
git bisect start 'HEAD' 'v4.19-rc7'
# good: [2fc8fb4c02a0f7b9d5e5b4de80cbcef7c808068b] Merge remote-tracking branch 'spi-nor/spi-nor/next'
git bisect good 2fc8fb4c02a0f7b9d5e5b4de80cbcef7c808068b
# good: [a54eefdf4d208f6904da9e836ff32d7dde0c9516] Merge remote-tracking branch 'tip/auto-latest'
git bisect good a54eefdf4d208f6904da9e836ff32d7dde0c9516
# good: [d71e0d25be750d02a3d04500aeb151bb94465811] Merge remote-tracking branch 'staging/staging-next'
git bisect good d71e0d25be750d02a3d04500aeb151bb94465811
# good: [7961c8ea9d81f927a78e30bb7c194310ed6b7c1d] Merge remote-tracking branch 'pinctrl/for-next'
git bisect good 7961c8ea9d81f927a78e30bb7c194310ed6b7c1d
# good: [c3d392e6aae57d54fdc683f7432c3e248602bebb] Merge remote-tracking branch 'xarray/xarray'
git bisect good c3d392e6aae57d54fdc683f7432c3e248602bebb
# good: [880c1034475c873963d6250eb95ebbbf5604a281] userfaultfd: selftest: cleanup help messages
git bisect good 880c1034475c873963d6250eb95ebbbf5604a281
# good: [9f1fa0ab60f7b09d335bbaf33db9116241059708] reiserfs: propagate errors from fill_with_dentries() properly
git bisect good 9f1fa0ab60f7b09d335bbaf33db9116241059708
# good: [596046ffd571f32fa3d3e7ffdf7861b71a258552] memblock: replace alloc_bootmem_low with memblock_alloc_low (2)
git bisect good 596046ffd571f32fa3d3e7ffdf7861b71a258552
# bad: [ef07e25e5bb02b420cb66004420cea3e0d65d107] dma-direct: fix up for the removal of linux/bootmem.h
git bisect bad ef07e25e5bb02b420cb66004420cea3e0d65d107
# good: [ddaa897c9ab76969a74d67a65b6616895f349644] memblock: replace alloc_bootmem with memblock_alloc
git bisect good ddaa897c9ab76969a74d67a65b6616895f349644
# good: [3b79243c2ef23d829a2f01f8c9526f17b80a7a32] memblock: rename free_all_bootmem to memblock_free_all
git bisect good 3b79243c2ef23d829a2f01f8c9526f17b80a7a32
# good: [d5fa9634892df2bc6bab6101f18df6ba5a2490c5] mm: remove nobootmem
git bisect good d5fa9634892df2bc6bab6101f18df6ba5a2490c5
# bad: [75fd637c22bc9bb5c959b7f93c2c5e5f0495992c] mm: remove include/linux/bootmem.h
git bisect bad 75fd637c22bc9bb5c959b7f93c2c5e5f0495992c
# good: [979961b3058df1a6d24ab423dd6fa6f20982f591] memblock: replace BOOTMEM_ALLOC_* with MEMBLOCK variants
git bisect good 979961b3058df1a6d24ab423dd6fa6f20982f591
# first bad commit: [75fd637c22bc9bb5c959b7f93c2c5e5f0495992c] mm: remove include/linux/bootmem.h
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 22:28 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <CAL_JsqLSBE9FFB7=o5bDJ1hxfNP6mAPJ-qXyEVHfY+xwfgDuWw@mail.gmail.com>
On Mon, Oct 15, 2018 at 05:13:08PM -0500, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 5:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 04:48:27PM -0500, Rob Herring wrote:
> > > On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > > > > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >
> > > > > > Hi Guenter,
> > > > > >
> > > > > > [Just cc'ing the PPC and devicetree folks]
> > > > > >
> > > > > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > >
> > > > > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > > > > >
> > > > > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > > > > >
> > > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > >
> > > > > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > > > >
> > > > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > > > > Modules linked in:
> > > > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > > > > IRQMASK: 1
> > > > > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > Call Trace:
> > > > > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > > > > >
> > > > > > >
> > > > > > > sparc images crash, starting with next-20181009. Bisect with
> > > > > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > > > > devicetree/for-next itself does not have the problem (bisect log
> > > > > > > attached below). The crash is in devicetree code.
> > > > > > >
> > > > > > > Crash logs:
> > > > > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> > > > >
> > > > > The sparc crash appears to be related to changes I made. Looking into it.
> > > > >
> > > >
> > > > Let me know if you need me to test anything or do some debugging.
> > >
> > > Well, I'm not having any luck getting sparc qemu to work. Here's what
> > > I'm trying with a sparc32_defconfig kernel:
> > >
> > > $ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
> > > 256 -no-reboot
> > > rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
> > > free=0x000000000000057a, addr=0x0000000000000000)
> > > qemu-system-sparc: rom check and register reset failed
> > >
> >
> > What is your qemu version ?
>
> 2.11 from ubuntu 18.04:
> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5)
>
This works for me:
qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
-drive file=hda.sqf,if=scsi,format=raw \
-append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \
-nographic -monitor none
arch/sparc/boot/image works as well.
This is with qemu 2.5 (from Ubuntu 16.04). I'll try with 2.11 tonight.
My current private version is based on qemu 3.0.
Guenter
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Guenter Roeck @ 2018-10-15 22:34 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <CAL_JsqLSBE9FFB7=o5bDJ1hxfNP6mAPJ-qXyEVHfY+xwfgDuWw@mail.gmail.com>
On Mon, Oct 15, 2018 at 05:13:08PM -0500, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 5:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Mon, Oct 15, 2018 at 04:48:27PM -0500, Rob Herring wrote:
> > > On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > > > > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >
> > > > > > Hi Guenter,
> > > > > >
> > > > > > [Just cc'ing the PPC and devicetree folks]
> > > > > >
> > > > > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > >
> > > > > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > > > > >
> > > > > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > > > > >
> > > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > >
> > > > > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > > > >
> > > > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > > > > Modules linked in:
> > > > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > > > > IRQMASK: 1
> > > > > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > Call Trace:
> > > > > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > > > > >
> > > > > > >
> > > > > > > sparc images crash, starting with next-20181009. Bisect with
> > > > > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > > > > devicetree/for-next itself does not have the problem (bisect log
> > > > > > > attached below). The crash is in devicetree code.
> > > > > > >
> > > > > > > Crash logs:
> > > > > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> > > > >
> > > > > The sparc crash appears to be related to changes I made. Looking into it.
> > > > >
> > > >
> > > > Let me know if you need me to test anything or do some debugging.
> > >
> > > Well, I'm not having any luck getting sparc qemu to work. Here's what
> > > I'm trying with a sparc32_defconfig kernel:
> > >
> > > $ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
> > > 256 -no-reboot
> > > rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
> > > free=0x000000000000057a, addr=0x0000000000000000)
> > > qemu-system-sparc: rom check and register reset failed
> > >
> >
> > What is your qemu version ?
>
> 2.11 from ubuntu 18.04:
> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5)
>
Update: Works for me with
QEMU emulator version 2.11.93 (Debian 1:2.12~rc3+dfsg-1)
with the following command line.
qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
-drive file=hda.sqf,if=scsi,format=raw \
-append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \
-nographic -monitor none
I have to enable DEVTMPFS and SQUASHFS for my root file system to work,
but otherwise it is sparc32_defconfig.
Guenter
^ permalink raw reply
* Re: linux-next: Tree for Oct 15
From: Rob Herring @ 2018-10-15 22:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, linux-next,
linuxppc-dev
In-Reply-To: <20181015223424.GA31977@roeck-us.net>
On Mon, Oct 15, 2018 at 5:34 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Mon, Oct 15, 2018 at 05:13:08PM -0500, Rob Herring wrote:
> > On Mon, Oct 15, 2018 at 5:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On Mon, Oct 15, 2018 at 04:48:27PM -0500, Rob Herring wrote:
> > > > On Mon, Oct 15, 2018 at 4:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > >
> > > > > On Mon, Oct 15, 2018 at 03:35:12PM -0500, Rob Herring wrote:
> > > > > > On Mon, Oct 15, 2018 at 3:12 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > > >
> > > > > > > Hi Guenter,
> > > > > > >
> > > > > > > [Just cc'ing the PPC and devicetree folks]
> > > > > > >
> > > > > > > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > > >
> > > > > > > > On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > > > > > > > >
> > > > > > > > > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
> > > > > > > >
> > > > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > > >
> > > > > > > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > > > > > > >
> > > > > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301 .memblock_alloc_range_nid+0x20/0x68
> > > > > > > > Modules linked in:
> > > > > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > > > > > > > NIP: c000000000f99198 LR: c000000000f99490 CTR: c000000000bb8364
> > > > > > > > REGS: c000000001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> > > > > > > > MSR: 0000000080021000 <CE,ME> CR: 24000422 XER: 20000000
> > > > > > > > IRQMASK: 1
> > > > > > > > GPR00: c000000000f99490 c000000001217d00 c00000000121a500 00000000000000c0
> > > > > > > > GPR04: 0000000000000000 0000000000000000 0000000000000000 ffffffffffffffff
> > > > > > > > GPR08: 0000000000000000 00000000000000c0 0000000000000018 00000000000000b7
> > > > > > > > GPR12: 0000000000000040 c000000000fe7840 0000000000000000 0000000000000000
> > > > > > > > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > > GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > > GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > > > > GPR28: c000000000000304 c000000001262088 00000000000000c0 c000000000fea500
> > > > > > > > NIP [c000000000f99198] .memblock_alloc_range_nid+0x20/0x68
> > > > > > > > LR [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > > Call Trace:
> > > > > > > > [c000000001217d00] [c000000002a00000] 0xc000000002a00000 (unreliable)
> > > > > > > > [c000000001217d80] [c000000000f99490] .memblock_alloc_base+0x18/0x48
> > > > > > > > [c000000001217df0] [c000000000f7a274] .allocate_paca_ptrs+0x3c/0x74
> > > > > > > > [c000000001217e70] [c000000000f78bf0] .early_init_devtree+0x288/0x320
> > > > > > > > [c000000001217f10] [c000000000f79b6c] .early_setup+0x80/0x130
> > > > > > > > [c000000001217f90] [c000000000000528] start_here_multiplatform+0x68/0x80
> > > > > > > >
> > > > > > > >
> > > > > > > > sparc images crash, starting with next-20181009. Bisect with
> > > > > > > > next-201810112 points to the merge of devicetree/for-next, though
> > > > > > > > devicetree/for-next itself does not have the problem (bisect log
> > > > > > > > attached below). The crash is in devicetree code.
> > > > > > > >
> > > > > > > > Crash logs:
> > > > > > > > https://kerneltests.org/builders/qemu-sparc64-next/builds/981/steps/qemubuildcommand_1/logs/stdio
> > > > > > > > https://kerneltests.org/builders/qemu-sparc-next/builds/975/steps/qemubuildcommand_1/logs/stdio
> > > > > >
> > > > > > The sparc crash appears to be related to changes I made. Looking into it.
> > > > > >
> > > > >
> > > > > Let me know if you need me to test anything or do some debugging.
> > > >
> > > > Well, I'm not having any luck getting sparc qemu to work. Here's what
> > > > I'm trying with a sparc32_defconfig kernel:
> > > >
> > > > $ qemu-system-sparc -kernel .build-sparc/vmlinux -M SS-4 -nographic -m
> > > > 256 -no-reboot
> > > > rom: requested regions overlap (rom phdr #0: .build-sparc/vmlinux.
> > > > free=0x000000000000057a, addr=0x0000000000000000)
> > > > qemu-system-sparc: rom check and register reset failed
> > > >
> > >
> > > What is your qemu version ?
> >
> > 2.11 from ubuntu 18.04:
> > QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5)
> >
>
> Update: Works for me with
> QEMU emulator version 2.11.93 (Debian 1:2.12~rc3+dfsg-1)
Seems to be some regression in 2.11.1. It works fine with my own build
with 3.0 based.
Rob
^ permalink raw reply
* Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
From: Joel Fernandes @ 2018-10-15 22:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-mips, Rich Felker, linux-ia64, linux-sh, Peter Zijlstra,
Catalin Marinas, Dave Hansen, Will Deacon, mhocko, linux-mm,
lokeshgidra, sparclinux, linux-riscv, kvmarm, Jonas Bonn,
linux-s390, dancol, Yoshinori Sato, Max Filippov, linux-hexagon,
Helge Deller, maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT,
hughd, James E.J. Bottomley, kasan-dev, elfring, Ingo Molnar,
Geert Uytterhoeven, Andrey Ryabinin, linux-snps-arc, kernel-team,
Sam Creasey, linux-xtensa, Jeff Dike, linux-alpha, linux-um,
Stefan Kristiansson, Julia Lawall, linux-m68k, Borislav Petkov,
Andy Lutomirski, Ley Foon Tan, kirill, Stafford Horne,
Guan Xuetao, Chris Zankel, Tony Luck, linux-parisc, pantin,
linux-kernel, Fenghua Yu, minchan, Thomas Gleixner,
Richard Weinberger, anton.ivanov, nios2-dev, akpm, linuxppc-dev,
David S. Miller
In-Reply-To: <20181015094209.GA31999@infradead.org>
On Mon, Oct 15, 2018 at 02:42:09AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations.
>
> Just curious: why?
In Android we have a requirement of moving a large (up to a GB now, but may
grow bigger in future) memory range from one location to another. This move
operation has to happen when the application threads are paused for this
operation. Therefore, an inefficient move like it is now (for example 250ms
on arm64) will cause response time issues for applications, which is not
acceptable. Huge pages cannot be used in such memory ranges to avoid this
inefficiency as (when the application threads are running) our fault handlers
are designed to process 4KB pages at a time, to keep response times low. So
using huge pages in this context can, again, cause response time issues.
Also, the mremap syscall waiting for quarter of a second for a large mremap
is quite weird and we ought to improve it where possible.
> > + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK)
> > + || old_end - old_addr < PMD_SIZE)
>
> The || goes on the first line.
Ok, fixed.
> > + } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) {
>
> Overly long line.
Ok, fixed. Preview of updated patch is below.
thanks,
- Joel
------8<---
From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Subject: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v3)
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slow across a large map. Turning on THP
may not be a viable option, and is not for us. This patch speeds up the
performance for non-THP system by copying at the PMD level when possible.
The speed up is three orders of magnitude. On a 1GB mremap, the mremap
completion times drops from 160-250 millesconds to 380-400 microseconds.
Before:
Total mremap time for 1GB data: 242321014 nanoseconds.
Total mremap time for 1GB data: 196842467 nanoseconds.
Total mremap time for 1GB data: 167051162 nanoseconds.
After:
Total mremap time for 1GB data: 385781 nanoseconds.
Total mremap time for 1GB data: 388959 nanoseconds.
Total mremap time for 1GB data: 402813 nanoseconds.
Incase THP is enabled, the optimization is mostly skipped except in
certain situations. I also flush the tlb every time we do this
optimization since I couldn't find a way to determine if the low-level
PTEs are dirty. It is seen that the cost of doing so is not much
compared the improvement, on both x86-64 and arm64.
Cc: minchan@kernel.org
Cc: pantin@google.com
Cc: hughd@google.com
Cc: lokeshgidra@google.com
Cc: dancol@google.com
Cc: mhocko@kernel.org
Cc: kirill@shutemov.name
Cc: akpm@linux-foundation.org
Cc: kernel-team@android.com
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
arch/Kconfig | 5 ++++
mm/mremap.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 6801123932a5..9724fe39884f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -518,6 +518,11 @@ config HAVE_IRQ_TIME_ACCOUNTING
Archs need to ensure they use a high enough resolution clock to
support irq time accounting and then call enable_sched_clock_irqtime().
+config HAVE_MOVE_PMD
+ bool
+ help
+ Archs that select this are able to move page tables at the PMD level.
+
config HAVE_ARCH_TRANSPARENT_HUGEPAGE
bool
diff --git a/mm/mremap.c b/mm/mremap.c
index 9e68a02a52b1..a8dd98a59975 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -191,6 +191,54 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
drop_rmap_locks(vma);
}
+static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
+ unsigned long new_addr, unsigned long old_end,
+ pmd_t *old_pmd, pmd_t *new_pmd, bool *need_flush)
+{
+ spinlock_t *old_ptl, *new_ptl;
+ struct mm_struct *mm = vma->vm_mm;
+
+ if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK) ||
+ old_end - old_addr < PMD_SIZE)
+ return false;
+
+ /*
+ * The destination pmd shouldn't be established, free_pgtables()
+ * should have release it.
+ */
+ if (WARN_ON(!pmd_none(*new_pmd)))
+ return false;
+
+ /*
+ * We don't have to worry about the ordering of src and dst
+ * ptlocks because exclusive mmap_sem prevents deadlock.
+ */
+ old_ptl = pmd_lock(vma->vm_mm, old_pmd);
+ if (old_ptl) {
+ pmd_t pmd;
+
+ new_ptl = pmd_lockptr(mm, new_pmd);
+ if (new_ptl != old_ptl)
+ spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
+
+ /* Clear the pmd */
+ pmd = *old_pmd;
+ pmd_clear(old_pmd);
+
+ VM_BUG_ON(!pmd_none(*new_pmd));
+
+ /* Set the new pmd */
+ set_pmd_at(mm, new_addr, new_pmd, pmd);
+ if (new_ptl != old_ptl)
+ spin_unlock(new_ptl);
+ spin_unlock(old_ptl);
+
+ *need_flush = true;
+ return true;
+ }
+ return false;
+}
+
unsigned long move_page_tables(struct vm_area_struct *vma,
unsigned long old_addr, struct vm_area_struct *new_vma,
unsigned long new_addr, unsigned long len,
@@ -239,7 +287,25 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
split_huge_pmd(vma, old_pmd, old_addr);
if (pmd_trans_unstable(old_pmd))
continue;
+ } else if (extent == PMD_SIZE &&
+ IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) {
+ /*
+ * If the extent is PMD-sized, try to speed the move by
+ * moving at the PMD level if possible.
+ */
+ bool moved;
+
+ if (need_rmap_locks)
+ take_rmap_locks(vma);
+ moved = move_normal_pmd(vma, old_addr, new_addr,
+ old_end, old_pmd, new_pmd,
+ &need_flush);
+ if (need_rmap_locks)
+ drop_rmap_locks(vma);
+ if (moved)
+ continue;
}
+
if (pte_alloc(new_vma->vm_mm, new_pmd))
break;
next = (new_addr + PMD_SIZE) & PMD_MASK;
--
2.19.1.331.ge82ca0e54c-goog
^ permalink raw reply related
* Re: linux-next: qemu boot failures with today's linux-next
From: Stephen Rothwell @ 2018-10-15 23:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux-Next Mailing List, PowerPC, Linux Kernel Mailing List
In-Reply-To: <87murfz8dl.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi Michael,
On Mon, 15 Oct 2018 23:45:10 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> > Preparing to boot Linux version 4.19.0-rc7 (sfr@ash) (gcc version 8.2.0 (Debian 8.2.0-4)) #2 SMP Mon Oct 15 18:53:28 AEDT 2018
> ^^^^^^^^^^
> I assume that's wrong, this is actually linux-next you're booting?
Yes, it was just before -rc8 came out and I suppress the extra version
information to save rebuilding things that depend on the version.
> > Booting Linux via __start() @ 0x0000000000400000 ...
>
> If you git Ctrl-a-c you should get the qemu prompt. Then you can run
> 'info registers' to print the regs and maybe see where it's stuck.
>
> And/or build with EARLY_DEBUG_LPAR to get early console output.
That gave one more line:
[ 0.000000] printk: bootconsole [udbg0] enabled
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/ioda/npu: Call skiboot's hot reset hook when disabling NPU2
From: Alistair Popple @ 2018-10-16 0:38 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: Reza Arbab, linuxppc-dev, David Gibson
In-Reply-To: <ac59afe1-cc7b-41f2-e19d-a7809d27b15a@ozlabs.ru>
Hi Alexey,
Looking at the skiboot side I think we only fence the NVLink bricks as part of a
PCIe function level reset (FLR) rather than a PCI Hot or Fundamental reset which
I believe is what the code here does. So to fence the bricks you would need to
do either a FLR on the given link or alter Skiboot to fence a given link as part
of a hot reset.
- Alistair
On Monday, 15 October 2018 6:17:51 PM AEDT Alexey Kardashevskiy wrote:
> Ping?
>
>
> On 02/10/2018 13:20, Alexey Kardashevskiy wrote:
> > The skiboot firmware has a hot reset handler which fences the NVIDIA V100
> > GPU RAM on Witherspoons and makes accesses no-op instead of throwing HMIs:
> > https://github.com/open-power/skiboot/commit/fca2b2b839a67
> >
> > Now we are going to pass V100 via VFIO which most certainly involves
> > KVM guests which are often terminated without getting a chance to offline
> > GPU RAM so we end up with a running machine with misconfigured memory.
> > Accessing this memory produces hardware management interrupts (HMI)
> > which bring the host down.
> >
> > To suppress HMIs, this wires up this hot reset hook to vfio_pci_disable()
> > via pci_disable_device() which switches NPU2 to a safe mode and prevents
> > HMIs.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > Changes:
> > v2:
> > * updated the commit log
> > ---
> > arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> > index cde7102..e37b9cc 100644
> > --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> > @@ -3688,6 +3688,15 @@ static void pnv_pci_release_device(struct pci_dev *pdev)
> > pnv_ioda_release_pe(pe);
> > }
> >
> > +static void pnv_npu_disable_device(struct pci_dev *pdev)
> > +{
> > + struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
> > + struct eeh_pe *eehpe = edev ? edev->pe : NULL;
> > +
> > + if (eehpe && eeh_ops && eeh_ops->reset)
> > + eeh_ops->reset(eehpe, EEH_RESET_HOT);
> > +}
> > +
> > static void pnv_pci_ioda_shutdown(struct pci_controller *hose)
> > {
> > struct pnv_phb *phb = hose->private_data;
> > @@ -3732,6 +3741,7 @@ static const struct pci_controller_ops pnv_npu_ioda_controller_ops = {
> > .reset_secondary_bus = pnv_pci_reset_secondary_bus,
> > .dma_set_mask = pnv_npu_dma_set_mask,
> > .shutdown = pnv_pci_ioda_shutdown,
> > + .disable_device = pnv_npu_disable_device,
> > };
> >
> > static const struct pci_controller_ops pnv_npu_ocapi_ioda_controller_ops = {
> >
>
>
^ permalink raw reply
* Re: [PATCH v06 3/5] migration/memory: Add hotplug READD_MULTIPLE
From: Michael Ellerman @ 2018-10-16 0:39 UTC (permalink / raw)
To: Michael Bringmann, linuxppc-dev
Cc: Nathan Fontenot, Michael Bringmann, Juliet Kim, Thomas Falcon,
Tyrel Datwyler
In-Reply-To: <f38687fe-7d46-830b-e4bb-ef78a7f99a65@linux.vnet.ibm.com>
Michael Bringmann <mwb@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 2b796da..9c76345 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -541,6 +549,23 @@ static int dlpar_memory_readd_by_index(u32 drc_index)
> return rc;
> }
>
> +static int dlpar_memory_readd_multiple(void)
> +{
> + struct drmem_lmb *lmb;
> + int rc;
> +
> + pr_info("Attempting to update multiple LMBs\n");
> +
> + for_each_drmem_lmb(lmb) {
> + if (drmem_lmb_update(lmb)) {
> + rc = dlpar_memory_readd_helper(lmb);
> + drmem_remove_lmb_update(lmb);
> + }
> + }
> +
> + return rc;
> +}
This leaves rc potentially uninitialised.
What should the result be in that case, -EINVAL ?
cheers
^ 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