Re: [PATCH v2 00/20] Fix handling of compat_siginfo_t

[Oleg Nesterov]

On 11/07, Andy Lutomirski wrote:
>
> On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras  wrote:
> > One issue that isn't resolved in this series is sending signals between a 
> > 32-bit
> > process and 64-bit process. Sending a si_int will work correctly, but a 
> > si_ptr
> > value will likely get corrupted due to the different layouts of the 32-bit 
> > and
> > 64-bit siginfo_t structures.
>
> This is so screwed up it's not even funny.

Agreed,

> A 64-bit big-endian compat calls rt_sigqueueinfo.  It passes in (among
> other things) a sigval_t.  The kernel can choose to interpret it

I always thought that the kernel should not interpret it at all. And indeed,
copy_siginfo_to_user() does

if (from->si_code < 0)
return __copy_to_user(to, from, sizeof(siginfo_t))

probably copy_siginfo_to_user32() should do something similar, at least
it should not truncate ->si_code it it is less than zero.

Not sure what signalfd_copyinfo() should do.

But perhaps I was wrong, I failed to find man sigqueueinfo, and man
sigqueue() documents that it passes sigval_t.


> BTW, x86 has its own set of screwups here.  Somehow cr2 and error_code
> ended up as part of ucontext instead of siginfo, which makes
> absolutely no sense to me and bloats task_struct.

Yes, and probably ->ip should have been the part of siginfo too. Say,
if you get SIGBUS you can't trust sc->ip if another signal was dequeued
before SIGBUS, in this case sc->ip will point to the handler of that
another signal. That is why we have SYNCHRONOUS_MASK and it helps, but
still this doesn't look nice.

Oleg.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Michael Ellerman]

On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:

> Any overlap in the reserved memory regions (those specified in the
> reserved-memory DT node) is a bug.  These bugs might go undetected as
> long as the contested region isn't used simultaneously by multiple
> software agents, which makes such bugs hard to debug.  Fix this by
> printing a scary warning during boot if overlap is detected.
> 
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 726ebe792813..62f467b8ccae 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
> reserved_mem *rmem)
>   return -ENOENT;
>  }
>  
> +static int __init __rmem_cmp(const void *a, const void *b)
> +{
> + const struct reserved_mem *ra = a, *rb = b;
> +
> + return ra->base - rb->base;
> +}
> +
> +static void __init __rmem_check_for_overlap(void)
> +{
> + int i;
> +
> + if (reserved_mem_count < 2)
> + return;
> +
> + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
> +  __rmem_cmp, NULL);
> + for (i = 0; i < reserved_mem_count - 1; i++) {
> + struct reserved_mem *this, *next;
> +
> + this = _mem[i];
> + next = _mem[i + 1];
> + if (!(this->base && next->base))
> + continue;
> + if (this->base + this->size > next->base) {
> + phys_addr_t this_end, next_end;
> +
> + this_end = this->base + this->size;
> + next_end = next->base + next->size;
> + WARN(1,
> +  "Reserved memory: OVERLAP DETECTED!\n%s (%pa--%pa) 
> overlaps with %s (%pa--%pa)\n",
> +  this->name, >base, _end,
> +  next->name, >base, _end);

This is blowing up on some powerpc machines.

It's too early in boot to call WARN() on these systems.

Can we turn it into a pr_err() for now?

I'll send a patch?

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Michael Ellerman]

On Mon, 2015-11-09 at 22:41 -0600, Rob Herring wrote:
> On Mon, Nov 9, 2015 at 10:29 PM, Michael Ellerman  wrote:
> > On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
> > > Any overlap in the reserved memory regions (those specified in the
> > > reserved-memory DT node) is a bug.  These bugs might go undetected as
> > > long as the contested region isn't used simultaneously by multiple
> > > software agents, which makes such bugs hard to debug.  Fix this by
> > > printing a scary warning during boot if overlap is detected.
> > > 
> > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > > index 726ebe792813..62f467b8ccae 100644
> > > --- a/drivers/of/of_reserved_mem.c
> > > +++ b/drivers/of/of_reserved_mem.c
> > > @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
> > > reserved_mem *rmem)
> > >   return -ENOENT;
> > >  }
> > > 
> > > +static int __init __rmem_cmp(const void *a, const void *b)
> > > +{
> > > + const struct reserved_mem *ra = a, *rb = b;
> > > +
> > > + return ra->base - rb->base;
> > > +}
> > > +
> > > +static void __init __rmem_check_for_overlap(void)
> > > +{
> > > + int i;
> > > +
> > > + if (reserved_mem_count < 2)
> > > + return;
> > > +
> > > + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
> > > +  __rmem_cmp, NULL);
> > > + for (i = 0; i < reserved_mem_count - 1; i++) {
> > > + struct reserved_mem *this, *next;
> > > +
> > > + this = _mem[i];
> > > + next = _mem[i + 1];
> > > + if (!(this->base && next->base))
> > > + continue;
> > > + if (this->base + this->size > next->base) {
> > > + phys_addr_t this_end, next_end;
> > > +
> > > + this_end = this->base + this->size;
> > > + next_end = next->base + next->size;
> > > + WARN(1,
> > > +  "Reserved memory: OVERLAP DETECTED!\n%s 
> > > (%pa--%pa) overlaps with %s (%pa--%pa)\n",
> > > +  this->name, >base, _end,
> > > +  next->name, >base, _end);
> > 
> > This is blowing up on some powerpc machines.
> > 
> > It's too early in boot to call WARN() on these systems.
> 
> I didn't realize WARN could not be used early. Good to know.

Yeah, it's a bit horrible.

It used to be even worse, we'd take a recursive trap and you'd get nothing
useful at all. Ben fixed that, which makes BUG work but not WARN, because WARN
requires you to take the trap _and return_. We should be able to fix it in the
medium term, but not immediately.

> > Can we turn it into a pr_err() for now?
> 
> Sounds fine.

> > I'll send a patch?
> 
> Great.

Thanks. I'll just test the final version and then send.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Rob Herring]

On Mon, Nov 9, 2015 at 10:29 PM, Michael Ellerman  wrote:
> On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
>
>> Any overlap in the reserved memory regions (those specified in the
>> reserved-memory DT node) is a bug.  These bugs might go undetected as
>> long as the contested region isn't used simultaneously by multiple
>> software agents, which makes such bugs hard to debug.  Fix this by
>> printing a scary warning during boot if overlap is detected.
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 726ebe792813..62f467b8ccae 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
>> reserved_mem *rmem)
>>   return -ENOENT;
>>  }
>>
>> +static int __init __rmem_cmp(const void *a, const void *b)
>> +{
>> + const struct reserved_mem *ra = a, *rb = b;
>> +
>> + return ra->base - rb->base;
>> +}
>> +
>> +static void __init __rmem_check_for_overlap(void)
>> +{
>> + int i;
>> +
>> + if (reserved_mem_count < 2)
>> + return;
>> +
>> + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
>> +  __rmem_cmp, NULL);
>> + for (i = 0; i < reserved_mem_count - 1; i++) {
>> + struct reserved_mem *this, *next;
>> +
>> + this = _mem[i];
>> + next = _mem[i + 1];
>> + if (!(this->base && next->base))
>> + continue;
>> + if (this->base + this->size > next->base) {
>> + phys_addr_t this_end, next_end;
>> +
>> + this_end = this->base + this->size;
>> + next_end = next->base + next->size;
>> + WARN(1,
>> +  "Reserved memory: OVERLAP DETECTED!\n%s 
>> (%pa--%pa) overlaps with %s (%pa--%pa)\n",
>> +  this->name, >base, _end,
>> +  next->name, >base, _end);
>
> This is blowing up on some powerpc machines.
>
> It's too early in boot to call WARN() on these systems.

I didn't realize WARN could not be used early. Good to know.

> Can we turn it into a pr_err() for now?

Sounds fine.

> I'll send a patch?

Great.

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] memory-hotplug: Fix kernel warning during memory hotplug on ppc64

[Nathan Fontenot]

On 11/03/2015 11:21 AM, John Allen wrote:
> This patch fixes a bug where a kernel warning is triggered when performing
> a memory hotplug on ppc64. This warning may also occur on any architecture
> that has multiple sections per memory block.
> 
> [   78.300767] [ cut here ]
> [   78.300768] WARNING: at ../drivers/base/memory.c:210
> [   78.300769] Modules linked in: rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag 
> inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c 
> ibmveth(X) rtc_generic btrfs xor raid6_pq xts gf128mul dm_crypt sd_mod sr_mod 
> cdrom crc_t10dif ibmvscsi(X) scsi_transport_srp scsi_tgt dm_mod sg scsi_mod 
> autofs4
> [   78.300789] Supported: Yes, External
> [   78.300791] CPU: 1 PID: 3090 Comm: systemd-udevd Tainted: G  X 
> 3.12.45-1-default #1
> [   78.300793] task: c004d7d1d970 ti: c004d7b9 task.ti: 
> c004d7b9
> [   78.300794] NIP: c04fcff8 LR: c04fda84 CTR: 
> 
> [   78.300795] REGS: c004d7b93930 TRAP: 0700   Tainted: G  X  
> (3.12.45-1-default)
> [   78.300796] MSR: 80029033   CR: 24088848  
> XER: 
> [   78.300800] CFAR: c04fcf98 SOFTE: 1
> GPR00: 0537 c004d7b93bb0 c0e7f200 00053000
> GPR04: 1000 0001 c0e0f200 
> GPR08:  0001 0537 014dc000
> GPR12: 00054000 ce7f0900 10041040 
> GPR16: 0100206f0010 1003ff78 1006c824 100410b0
> GPR20: 1003ff90 1006c00c 01002073cd20 0100206f0760
> GPR24: 0100206f85a0 c076d950 c004ef7c95e0 c004d7b93e00
> GPR28: c004de601738 0001 c1218f80 003f
> [   78.300818] NIP [c04fcff8] memory_block_action+0x258/0x2e0
> [   78.300820] LR [c04fda84] memory_subsys_online+0x54/0x100
> [   78.300821] Call Trace:
> [   78.300822] [c004d7b93bb0] [c9071ce0] 0xc9071ce0 
> (unreliable)
> [   78.300824] [c004d7b93c40] [c04fda84] 
> memory_subsys_online+0x54/0x100
> [   78.300826] [c004d7b93c70] [c04df784] device_online+0xb4/0x120
> [   78.300828] [c004d7b93cb0] [c04fd738] 
> store_mem_state+0x88/0x220
> [   78.300830] [c004d7b93cf0] [c04db448] dev_attr_store+0x68/0xa0
> [   78.300833] [c004d7b93d30] [c031f938] 
> sysfs_write_file+0xf8/0x1d0
> [   78.300835] [c004d7b93d90] [c027d29c] vfs_write+0xec/0x250
> [   78.300837] [c004d7b93de0] [c027dfdc] SyS_write+0x6c/0xf0
> [   78.300839] [c004d7b93e30] [c000a17c] syscall_exit+0x0/0x7c
> [   78.300840] Instruction dump:
> [   78.300841] 780a0560 79482ea4 7ce94214 2fa7 41de0014 7d09402a 396b4000 
> 7907ffe3
> [   78.300844] 4082ff54 3cc2fff9 8926b83a 69290001 <0b09> 2fa9 
> 40de006c 3860fff0
> [   78.300847] ---[ end trace dfec8da06ebbc762 ]---
> 
> The warning is triggered because there is a udev rule that automatically
> tries to online memory after it has been added. The udev rule varies from
> distro to distro, but will generally look something like:
> 
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", 
> ATTR{state}="online"
> 
> On any architecture that uses memory_probe_store to reserve memory,
> this can interrupt the memory reservation process. This patch modifies
> memory_probe_store to take the hotplug sysfs lock to prevent the online
> of added memory before the completion of the probe.
> 
> Signed-off-by: John Allen 

Reviewed-by: Nathan Fontenot 

> ---
> v2: Move call to unlock_device_hotplug under "out" label
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index bece691..7c50415 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -422,6 +422,10 @@ memory_probe_store(struct device *dev, struct 
> device_attribute *attr,
>   if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
>   return -EINVAL;
> 
> + ret = lock_device_hotplug_sysfs();
> + if (ret)
> + return ret;
> +
>   for (i = 0; i < sections_per_block; i++) {
>   nid = memory_add_physaddr_to_nid(phys_addr);
>   ret = add_memory(nid, phys_addr,
> @@ -434,6 +438,7 @@ memory_probe_store(struct device *dev, struct 
> device_attribute *attr,
> 
>   ret = count;
>  out:
> + unlock_device_hotplug();
>   return ret;
>  }
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Laurent Vivier]

Le 10/11/2015 01:29, Michael Ellerman a écrit :
> On Sat, 2015-11-07 at 12:35 +0100, Laurent Vivier wrote:
>> Le 07/11/2015 00:24, Scott Wood a écrit :
>>> On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
 Le 06/11/2015 22:09, Scott Wood a écrit :
> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>> When I try to cross compile a ppc64 kernel, it generally
>> fails on the VDSO stage. This is true for powerpc64 cross-
>> compiler, but also when I try to build a ppc64le kernel
>> on a ppc64 host.
>>
>> VDSO64L fails:
>>
>>   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
>> /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
>> file class ELFCLASS64 incompatible with ELFCLASS32
>> /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
>>
>> This fails because gcc calls "collect2" with
>> "--oformat elf32-powerpcle" with ppc64 objects, without the
>> "--oformat" ld works well because it use the format of the
>> first object as output format.
>>
>> As this case is correctly managed to build the other kernel
>> objects, this patch replaces $(GCC) by $(LD) to generate the
>> VDSO objects.
>>>
 So at this point, I can:

 1- either fix my compiler,
 2- or fix the vdso64 linker command.
>>>
>> Thank you Scott. With the help of the comment from Segher, I can choose
>> #1 now :)
> 
> What distro/toolchain did you hit this on?

fedora 23.

> I actually wrote this same patch a while back, but from memory it broke in 
> some
> configurations. So I never merged it. I'll see if I can find my notes and work
> out exactly why it didn't work, maybe we should merge it anyway, even though
> the real bug is a toolchain bug.

On fedora, there is also a bug in binutils configuration where ld is not
able to manage ppc64le binaries on ppc64 host, but I've already sent a
fix for that and it is now in rawhide (will be in fedora 24).

https://bugzilla.redhat.com/show_bug.cgi?id=1275709

Laurent
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] platforms/powernv: Add support for Nvlink NPUs

[Alistair Popple]

NV-Link is a high speed interconnect that is used in conjunction with
a PCI-E connection to create an interface between CPU and GPU that
provides very high data bandwidth. A PCI-E connection to a GPU is used
as the control path to initiate and report status of large data
transfers sent via the NV-Link.

On IBM Power systems the NV-Link hardware interface is very similar to
the existing PHB3. This patch adds support for this new NPU PHB
type. DMA operations on the NPU are not supported as this patch sets
the TCE translation tables to be the same as the related GPU PCIe
device for each Nvlink. Therefore all DMA operations are setup and
controlled via the PCIe device.

EEH is not presently supported for the NPU devices, although it may be
added in future.

Signed-off-by: Alistair Popple 
Signed-off-by: Gavin Shan 
---

This patch includes the following changes from v1:
 - Minor variable name updates and code refactors suggested by Gavin
 - Fixes for an issue with TCE cache invalidation

 arch/powerpc/include/asm/pci.h|   4 +
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/npu-dma.c  | 339 ++
 arch/powerpc/platforms/powernv/pci-ioda.c | 132 +++-
 arch/powerpc/platforms/powernv/pci.c  |   4 +
 arch/powerpc/platforms/powernv/pci.h  |  19 ++
 6 files changed, 488 insertions(+), 12 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/npu-dma.c

diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 3453bd8..6f8065a 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -149,4 +149,8 @@ extern void pcibios_setup_phb_io_space(struct 
pci_controller *hose);
 extern void pcibios_scan_phb(struct pci_controller *hose);

 #endif /* __KERNEL__ */
+
+extern struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev);
+extern struct pci_dev *pnv_pci_get_npu_dev(struct pci_dev *gpdev, int index);
+
 #endif /* __ASM_POWERPC_PCI_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 1c8cdb6..ee774e8 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,7 +4,7 @@ obj-y   += rng.o opal-elog.o opal-dump.o 
opal-sysparam.o opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o

 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
-obj-$(CONFIG_PCI)  += pci.o pci-p5ioc2.o pci-ioda.o
+obj-$(CONFIG_PCI)  += pci.o pci-p5ioc2.o pci-ioda.o npu-dma.o
 obj-$(CONFIG_EEH)  += eeh-powernv.o
 obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
 obj-$(CONFIG_MEMORY_FAILURE)   += opal-memory-errors.o
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
new file mode 100644
index 000..a1e5ba5
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -0,0 +1,339 @@
+/*
+ * This file implements the DMA operations for Nvlink devices. The NPU
+ * devices all point to the same iommu table as the parent PCI device.
+ *
+ * Copyright Alistair Popple, IBM Corporation 2015.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "powernv.h"
+#include "pci.h"
+
+static struct pci_dev *get_pci_dev(struct device_node *dn)
+{
+   return PCI_DN(dn)->pcidev;
+}
+
+/* Given a NPU device get the associated PCI device. */
+struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev)
+{
+   struct device_node *dn;
+   struct pci_dev *gpdev;
+
+   /* Get assoicated PCI device */
+   dn = of_parse_phandle(npdev->dev.of_node, "ibm,gpu", 0);
+   if (!dn)
+   return NULL;
+
+   gpdev = get_pci_dev(dn);
+   of_node_put(dn);
+
+   return gpdev;
+}
+EXPORT_SYMBOL(pnv_pci_get_gpu_dev);
+
+/* Given the real PCI device get a linked NPU device. */
+struct pci_dev *pnv_pci_get_npu_dev(struct pci_dev *gpdev, int index)
+{
+   struct device_node *dn;
+   struct pci_dev *npdev;
+
+   /* Get assoicated PCI device */
+   dn = of_parse_phandle(gpdev->dev.of_node, "ibm,npu", index);
+   if (!dn)
+   return NULL;
+
+   npdev = get_pci_dev(dn);
+   of_node_put(dn);
+
+   return npdev;
+}
+EXPORT_SYMBOL(pnv_pci_get_npu_dev);
+
+#define NPU_DMA_OP_UNSUPPORTED()   \
+   dev_err_once(dev, "%s operation unsupported for Nvlink devices\n", \
+   __func__)
+
+static void *dma_npu_alloc(struct device *dev, size_t size,
+  dma_addr_t *dma_handle, gfp_t flag,
+  struct dma_attrs *attrs)
+{

[PATCH] of: Print rather than WARN'ing when overlap check fails

[Michael Ellerman]

__rmem_check_for_overlap() is called very early in boot, and on some
powerpc systems it's not safe to call WARN that early in boot.

If the overlap check fails the system will oops instead of printing a
warning. Furthermore because it's so early in boot the console is not up
and the user doesn't see the oops, they just get a dead system.

Fix it by printing an error instead of calling WARN.

Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions")
Signed-off-by: Michael Ellerman 
---
 drivers/of/of_reserved_mem.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 62f467b8ccae..49703916a30e 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -226,10 +226,9 @@ static void __init __rmem_check_for_overlap(void)
 
this_end = this->base + this->size;
next_end = next->base + next->size;
-   WARN(1,
-"Reserved memory: OVERLAP DETECTED!\n%s (%pa--%pa) 
overlaps with %s (%pa--%pa)\n",
-this->name, >base, _end,
-next->name, >base, _end);
+   pr_err("Reserved memory: OVERLAP DETECTED!\n%s 
(%pa--%pa) overlaps with %s (%pa--%pa)\n",
+  this->name, >base, _end,
+  next->name, >base, _end);
}
}
 }
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 0/3]perf/core: extend perf_reg and perf_sample_regs_intr

[Michael Ellerman]

On Fri, 2015-11-06 at 11:25 +0100, Peter Zijlstra wrote:

> On Fri, Nov 06, 2015 at 09:04:00PM +1100, Michael Ellerman wrote:

> > It's a perrenial request from our hardware PMU folks to be able to see the 
> > raw
> > values of the PMU registers.
> > 
> > I think partly it's so that they can verify that perf is doing what they 
> > want,
> > and some of it is that they're interested in some of the more obscure info 
> > that
> > isn't plumbed out through other perf interfaces.
> > 
> > We've used various internal hacks over the years to keep them happy. This 
> > is an
> > attempt to use a somewhat standard mechanism.
> > 
> > It would also be helpful for those of us working on the perf hardware 
> > backends,
> > to be able to verify that we're programming things correctly, without 
> > resorting
> > to debug printks etc.
> > 
> > Basically we want to sample regs at the time of the perf interrupt, so we
> > though PERF_SAMPLE_REGS_INTR made senes :)
> > 
> > But if you think this is the wrong mechanism within perf, then please let us
> > know.
> > 
> > I know perf's mission is to abstract as much of the arcane hardware details
> > into a generic interface and make PMUs actually useful for normal folks, 
> > and we
> > are committed to that, but it would also be useful to be able to get the raw
> > values for a different type of user.
> > 
> > Maddy's patch only exports PMC1-6 and MMCR0/1. I think we also need to 
> > export
> > some others, in particular MMCRA has a lot of stuff in it, half of which is 
> > not
> > even architected. So that would have to be exported as "POWER8_MMCRA". And 
> > then
> > there's the SIAR/SDAR/SIER which contain a bunch of info on sampled
> > instructions that is not currently plumbed out.
> 
> OK, no objections then. But this is useful information and should be
> included in the patch set.

Thanks, yeah definitely needs more explanation in the patch set.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Michael Ellerman]

On Sat, 2015-11-07 at 12:35 +0100, Laurent Vivier wrote:
> Le 07/11/2015 00:24, Scott Wood a écrit :
> > On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
> > > Le 06/11/2015 22:09, Scott Wood a écrit :
> > > > On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
> > > > > When I try to cross compile a ppc64 kernel, it generally
> > > > > fails on the VDSO stage. This is true for powerpc64 cross-
> > > > > compiler, but also when I try to build a ppc64le kernel
> > > > > on a ppc64 host.
> > > > > 
> > > > > VDSO64L fails:
> > > > > 
> > > > >   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
> > > > > /usr/bin/powerpc64-linux-gnu-ld: 
> > > > > arch/powerpc/kernel/vdso64/sigtramp.o:
> > > > > file class ELFCLASS64 incompatible with ELFCLASS32
> > > > > /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong 
> > > > > format
> > > > > 
> > > > > This fails because gcc calls "collect2" with
> > > > > "--oformat elf32-powerpcle" with ppc64 objects, without the
> > > > > "--oformat" ld works well because it use the format of the
> > > > > first object as output format.
> > > > > 
> > > > > As this case is correctly managed to build the other kernel
> > > > > objects, this patch replaces $(GCC) by $(LD) to generate the
> > > > > VDSO objects.
> > 
> > > So at this point, I can:
> > > 
> > > 1- either fix my compiler,
> > > 2- or fix the vdso64 linker command.
> > 
> Thank you Scott. With the help of the comment from Segher, I can choose
> #1 now :)

What distro/toolchain did you hit this on?

I actually wrote this same patch a while back, but from memory it broke in some
configurations. So I never merged it. I'll see if I can find my notes and work
out exactly why it didn't work, maybe we should merge it anyway, even though
the real bug is a toolchain bug.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] memory-hotplug: Fix kernel warning during memory hotplug on ppc64

[Michael Ellerman]

Hi John,

On Tue, 2015-11-03 at 11:21 -0600, John Allen wrote:
> This patch fixes a bug where a kernel warning is triggered when performing
> a memory hotplug on ppc64. This warning may also occur on any architecture
> that has multiple sections per memory block.

So it looks like the only arches that enable this code at all are powerpc, sh
and x86 (via CONFIG_ARCH_MEMORY_PROBE). And it sounds like on x86 it's just
there for debugging, ACPI is meant to notify you of memory hotplug by the
sounds.

Do any of sh or x86 have "multiple sections per memory block" ?

If not then this bug would only apply to powerpc, which would be useful to
know.

And what is the actual warning? ie. what does the code look like. My line 210
of memory.c is a printk() not a WARN.


> [   78.300767] [ cut here ]
> [   78.300768] WARNING: at ../drivers/base/memory.c:210
> [   78.300769] Modules linked in: rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag 
> inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c 
> ibmveth(X) rtc_generic btrfs xor raid6_pq xts
> gf128mul dm_crypt sd_mod sr_mod cdrom crc_t10dif ibmvscsi(X) 
> scsi_transport_srp scsi_tgt dm_mod sg scsi_mod autofs4
> [   78.300789] Supported: Yes, External
> [   78.300791] CPU: 1 PID: 3090 Comm: systemd-udevd Tainted: G  X 
> 3.12.45-1-default #1
> [   78.300793] task: c004d7d1d970 ti: c004d7b9 task.ti: 
> c004d7b9
> [   78.300794] NIP: c04fcff8 LR: c04fda84 CTR: 
> 
> [   78.300795] REGS: c004d7b93930 TRAP: 0700   Tainted: G  X  
> (3.12.45-1-default)
> [   78.300796] MSR: 80029033   CR: 24088848  
> XER: 
> [   78.300800] CFAR: c04fcf98 SOFTE: 1
> GPR00: 0537 c004d7b93bb0 c0e7f200 00053000
> GPR04: 1000 0001 c0e0f200 
> GPR08:  0001 0537 014dc000
> GPR12: 00054000 ce7f0900 10041040 
> GPR16: 0100206f0010 1003ff78 1006c824 100410b0
> GPR20: 1003ff90 1006c00c 01002073cd20 0100206f0760
> GPR24: 0100206f85a0 c076d950 c004ef7c95e0 c004d7b93e00
> GPR28: c004de601738 0001 c1218f80 003f
> [   78.300818] NIP [c04fcff8] memory_block_action+0x258/0x2e0
> [   78.300820] LR [c04fda84] memory_subsys_online+0x54/0x100
> [   78.300821] Call Trace:
> [   78.300822] [c004d7b93bb0] [c9071ce0] 0xc9071ce0 
> (unreliable)
> [   78.300824] [c004d7b93c40] [c04fda84] 
> memory_subsys_online+0x54/0x100
> [   78.300826] [c004d7b93c70] [c04df784] device_online+0xb4/0x120
> [   78.300828] [c004d7b93cb0] [c04fd738] 
> store_mem_state+0x88/0x220
> [   78.300830] [c004d7b93cf0] [c04db448] dev_attr_store+0x68/0xa0
> [   78.300833] [c004d7b93d30] [c031f938] 
> sysfs_write_file+0xf8/0x1d0
> [   78.300835] [c004d7b93d90] [c027d29c] vfs_write+0xec/0x250
> [   78.300837] [c004d7b93de0] [c027dfdc] SyS_write+0x6c/0xf0
> [   78.300839] [c004d7b93e30] [c000a17c] syscall_exit+0x0/0x7c
> [   78.300840] Instruction dump:
> [   78.300841] 780a0560 79482ea4 7ce94214 2fa7 41de0014 7d09402a 396b4000 
> 7907ffe3
> [   78.300844] 4082ff54 3cc2fff9 8926b83a 69290001 <0b09> 2fa9 
> 40de006c 3860fff0
> [   78.300847] ---[ end trace dfec8da06ebbc762 ]---

For change logs I think it's nice to trim the oops a bit. Others probably have
different opinions but I'd remove the printk timestamp, the GPRs and some of
the other regs and the instruction dump, so more like:

  WARNING: at ../drivers/base/memory.c:210
  CPU: 1 PID: 3090 Comm: systemd-udevd Tainted: G  X 
3.12.45-1-default #1
  NIP [c04fcff8] memory_block_action+0x258/0x2e0
  LR [c04fda84] memory_subsys_online+0x54/0x100
  Call Trace:
  [c004d7b93bb0] [c9071ce0] 0xc9071ce0 (unreliable)
  [c004d7b93c40] [c04fda84] memory_subsys_online+0x54/0x100
  [c004d7b93c70] [c04df784] device_online+0xb4/0x120
  [c004d7b93cb0] [c04fd738] store_mem_state+0x88/0x220
  [c004d7b93cf0] [c04db448] dev_attr_store+0x68/0xa0
  [c004d7b93d30] [c031f938] sysfs_write_file+0xf8/0x1d0
  [c004d7b93d90] [c027d29c] vfs_write+0xec/0x250
  [c004d7b93de0] [c027dfdc] SyS_write+0x6c/0xf0
  [c004d7b93e30] [c000a17c] syscall_exit+0x0/0x7c


Also looking at the trace, it's from 3.12.45-1, which is pretty old. Have you
also tested on mainline?

> The warning is triggered because there is a udev rule that automatically
> tries to online memory after it has been added. The udev rule varies from
> distro to distro, but will generally look something like:
> 
> SUBSYSTEM=="memory", ACTION=="add",