* Re: powerpc/pseries: add missing cpumask.h include file
From: Michael Ellerman @ 2018-10-31 5:43 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: nfont, linuxppc-dev, Tyrel Datwyler
In-Reply-To: <1540258332-15520-1-git-send-email-tyreld@linux.vnet.ibm.com>
On Tue, 2018-10-23 at 01:32:12 UTC, Tyrel Datwyler wrote:
> Build error is encountered when inlcuding <asm/rtas.h> if no explicit or
> implicit include of cpumask.h exists in the including file.
>
> In file included from arch/powerpc/platforms/pseries/hotplug-pci.c:3:0:
> ./arch/powerpc/include/asm/rtas.h:360:34: error: unknown type name 'cpumask_var_t'
> extern int rtas_online_cpus_mask(cpumask_var_t cpus);
> ^
> ./arch/powerpc/include/asm/rtas.h:361:35: error: unknown type name 'cpumask_var_t'
> extern int rtas_offline_cpus_mask(cpumask_var_t cpus);
>
> Fixes: 120496ac2d2d ("powerpc: Bring all threads online prior to migration/hibernation")
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8dce6b2215eaa91dbf04463e11098a
cheers
^ permalink raw reply
* Re: selftests/powerpc: Fix ptrace tm failure
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Breno Leitao, linuxppc-dev; +Cc: Breno Leitao, mikey, stable, gromero
In-Reply-To: <1540242986-7510-1-git-send-email-leitao@debian.org>
On Mon, 2018-10-22 at 21:16:26 UTC, Breno Leitao wrote:
> Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation
> fault that happens on the child process prior to setting cptr[2] = 1. This
> causes the parent process to wait forever at 'while (!pptr[2])' and the test to
> be killed by the test harness framework by timeout, thus, failing.
>
> The segmentation fault happens because of a inline assembly being
> generated as:
>
> 0x10000355c <tm_spd_gpr+492> lfs f0, 0(0)
>
> This is reading memory position 0x0 and causing the segmentation fault.
>
> This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where
> flt_4 is passed to the inline assembly block as:
>
> [flt_4] "r" (&d)
>
> Since the inline assembly 'r' constraint means any GPR, gpr0 is being
> chosen, thus causing this issue when issuing a Load Floating-Point Single
> instruction.
>
> This patch simply changes the constraint to 'b', which specify that this
> register will be used as base, and r0 is not allowed to be used, avoiding
> this issue.
>
> Other than that, removing flt_2 register from the input operands, since it
> is not used by the inline assembly code at all.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/48dc0ef19044bfb69193302fbe3a83
cheers
^ permalink raw reply
* Re: [v2] KVM: PPC: Use exported tb_to_ns() function in decrementer emulation
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Paul Mackerras, kvm, kvm-ppc; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20181020095455.GA12489@blackberry>
On Sat, 2018-10-20 at 09:54:55 UTC, Paul Mackerras wrote:
> This changes the KVM code that emulates the decrementer function to do
> the conversion of decrementer values to time intervals in nanoseconds
> by calling the tb_to_ns() function exported by the powerpc timer code,
> in preference to open-coded arithmetic using values from the
> decrementer_clockevent struct. Similarly, the HV-KVM code that did
> the same conversion using arithmetic on tb_ticks_per_sec also now
> uses tb_to_ns().
>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c43befca86ae35cc82bd889484bd17
cheers
^ permalink raw reply
* Re: [v6,08/20] powerpc/8xx: Use patch_site for perf counters setup
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <231cb98301edd62a0e9f444044ef6ab535733da6.1539931702.git.christophe.leroy@c-s.fr>
On Fri, 2018-10-19 at 06:55:08 UTC, Christophe Leroy wrote:
> The 8xx TLB miss routines are patched when (de)activating
> perf counters.
>
> This patch uses the new patch_site functionality in order
> to get a better code readability and avoid a label mess when
> dumping the code with 'objdump -d'
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/709cf19c5749308603ffa12557d8bd
cheers
^ permalink raw reply
* Re: [v6,07/20] powerpc/8xx: Use patch_site for memory setup patching
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c75a3503a979bbb1873bfb2749e03cfc040052ae.1539931702.git.christophe.leroy@c-s.fr>
On Fri, 2018-10-19 at 06:55:06 UTC, Christophe Leroy wrote:
> The 8xx TLB miss routines are patched at startup at several places.
>
> This patch uses the new patch_site functionality in order
> to get a better code readability and avoid a label mess when
> dumping the code with 'objdump -d'
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1a210878bf21de3f60646c13001d04
cheers
^ permalink raw reply
* Re: [v6, 06/20] powerpc/code-patching: add a helper to get the address of a patch_site
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <767ba67010bfd4ec8832bbd43eca9e419e122d7e.1539931702.git.christophe.leroy@c-s.fr>
On Fri, 2018-10-19 at 06:55:04 UTC, Christophe Leroy wrote:
> This patch adds a helper to get the address of a patch_site
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/082e2869fc022de4db9977e06558da
cheers
^ permalink raw reply
* Re: [v6, 01/20] Revert "powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP"
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <944206be46c14b9f0578f385bdc653a9c3b8cfe2.1539931702.git.christophe.leroy@c-s.fr>
On Fri, 2018-10-19 at 06:54:54 UTC, Christophe Leroy wrote:
> This reverts commit 4f94b2c7462d9720b2afa7e8e8d4c19446bb31ce.
>
> That commit was buggy, as it used rlwinm instead of rlwimi.
> Instead of fixing that bug, we revert the previous commit in order to
> reduce the dependency between L1 entries and L2 entries
>
> Fixes: 4f94b2c7462d9 ("powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cc4ebf5c0a3440ed0a32d25c55ebdb
cheers
^ permalink raw reply
* Re: powerpc/pseries: Export maximum memory value
From: Michael Ellerman @ 2018-10-31 5:42 UTC (permalink / raw)
To: Aravinda Prasad, linuxppc-dev; +Cc: nfont, naveen.n.rao, aravinda
In-Reply-To: <153916697991.21165.5694207762066031403.stgit@aravinda>
On Wed, 2018-10-10 at 10:22:59 UTC, Aravinda Prasad wrote:
> This patch exports the maximum possible amount of memory
> configured on the system via /proc/powerpc/lparcfg.
>
> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/772b039fd9a7e12d5fc80e6f649341
cheers
^ permalink raw reply
* Re: [PATCH 5/6] pci: layerscape: Add the EP mode support.
From: Kishon Vijay Abraham I @ 2018-10-31 4:15 UTC (permalink / raw)
To: Xiaowei Bao, bhelgaas@google.com, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, Leo Li,
lorenzo.pieralisi@arm.com, arnd@arndb.de,
gregkh@linuxfoundation.org, M.h. Lian, Mingkai Hu, Roy Zang,
kstewart@linuxfoundation.org, cyrille.pitchen@free-electrons.com,
pombredanne@nexb.com, shawn.lin@rock-chips.com,
niklas.cassel@axis.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Cc: Jiafei Pan
In-Reply-To: <HE1PR04MB14979058170FA16A7465FF9EF5CD0@HE1PR04MB1497.eurprd04.prod.outlook.com>
Hi,
On 31/10/18 8:03 AM, Xiaowei Bao wrote:
>
>
> -----Original Message-----
> From: Xiaowei Bao
> Sent: 2018年10月26日 17:19
> To: 'Kishon Vijay Abraham I' <kishon@ti.com>; bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org; cyrille.pitchen@free-electrons.com; pombredanne@nexb.com; shawn.lin@rock-chips.com; niklas.cassel@axis.com; linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Cc: Jiafei Pan <jiafei.pan@nxp.com>
> Subject: RE: [PATCH 5/6] pci: layerscape: Add the EP mode support.
>
>
>
> -----Original Message-----
> From: Kishon Vijay Abraham I <kishon@ti.com>
> Sent: 2018年10月26日 13:29
> To: Xiaowei Bao <xiaowei.bao@nxp.com>; bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org; cyrille.pitchen@free-electrons.com; pombredanne@nexb.com; shawn.lin@rock-chips.com; niklas.cassel@axis.com; linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 5/6] pci: layerscape: Add the EP mode support.
>
> Hi,
>
> On Thursday 25 October 2018 04:39 PM, Xiaowei Bao wrote:
>> Add the PCIe EP mode support for layerscape platform.
>>
>> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>> ---
>> drivers/pci/controller/dwc/Makefile | 2 +-
>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 161
>> ++++++++++++++++++++++++
>> 2 files changed, 162 insertions(+), 1 deletions(-) create mode
>> 100644 drivers/pci/controller/dwc/pci-layerscape-ep.c
>>
>> diff --git a/drivers/pci/controller/dwc/Makefile
>> b/drivers/pci/controller/dwc/Makefile
>> index 5d2ce72..b26d617 100644
>> --- a/drivers/pci/controller/dwc/Makefile
>> +++ b/drivers/pci/controller/dwc/Makefile
>> @@ -8,7 +8,7 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
>> obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
>> obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>> obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>> -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>> +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
>> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
>> obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>> obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o diff --git
>> a/drivers/pci/controller/dwc/pci-layerscape-ep.c
>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
>> new file mode 100644
>> index 0000000..3b33bbc
>> --- /dev/null
>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
>> @@ -0,0 +1,161 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PCIe controller EP driver for Freescale Layerscape SoCs
>> + *
>> + * Copyright (C) 2018 NXP Semiconductor.
>> + *
>> + * Author: Xiaowei Bao <xiaowei.bao@nxp.com> */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/of_pci.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/of_address.h>
>> +#include <linux/pci.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/resource.h>
>> +
>> +#include "pcie-designware.h"
>> +
>> +#define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
>
> The base address should come from dt.
>> +
>> +struct ls_pcie_ep {
>> + struct dw_pcie *pci;
>> +};
>> +
>> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
>> +
>> +static bool ls_pcie_is_bridge(struct ls_pcie_ep *pcie) {
>> + struct dw_pcie *pci = pcie->pci;
>> + u32 header_type;
>> +
>> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
>> + header_type &= 0x7f;
>> +
>> + return header_type == PCI_HEADER_TYPE_BRIDGE; }
>> +
>> +static int ls_pcie_establish_link(struct dw_pcie *pci) {
>> + return 0;
>> +}
>
> There should be some way by which EP should tell RC that it is not configured yet. Are there no bits to control LTSSM state initialization or Configuration retry status enabling?
> [Xiaowei Bao] There have not bits to control LTSSM state to tell the RC it is configured. The start link is auto completed.
> [Xiaowei Bao] Hi Kishon, is there any advice?
If there is no HW support, I don't think anything could be done here. This
could result in RC reading configuration space even before EP is fully initialized.
>> +
>> +static const struct dw_pcie_ops ls_pcie_ep_ops = {
>> + .start_link = ls_pcie_establish_link, };
>> +
>> +static const struct of_device_id ls_pcie_ep_of_match[] = {
>> + { .compatible = "fsl,ls-pcie-ep",},
>> + { },
>> +};
>> +
>> +static void ls_pcie_ep_init(struct dw_pcie_ep *ep) {
>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> + struct pci_epc *epc = ep->epc;
>> + enum pci_barno bar;
>> +
>> + for (bar = BAR_0; bar <= BAR_5; bar++)
>> + dw_pcie_ep_reset_bar(pci, bar);
>> +
>> + epc->features |= EPC_FEATURE_NO_LINKUP_NOTIFIER; }
>> +
>> +static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>> + enum pci_epc_irq_type type, u16 interrupt_num) {
>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> +
>> + switch (type) {
>> + case PCI_EPC_IRQ_LEGACY:
>> + return dw_pcie_ep_raise_legacy_irq(ep, func_no);
>> + case PCI_EPC_IRQ_MSI:
>> + return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
>> + case PCI_EPC_IRQ_MSIX:
>> + return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
>> + default:
>> + dev_err(pci->dev, "UNKNOWN IRQ type\n");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct dw_pcie_ep_ops pcie_ep_ops = {
>> + .ep_init = ls_pcie_ep_init,
>> + .raise_irq = ls_pcie_ep_raise_irq,
>> +};
>> +
>> +static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
>> + struct platform_device *pdev)
>> +{
>> + struct dw_pcie *pci = pcie->pci;
>> + struct device *dev = pci->dev;
>> + struct dw_pcie_ep *ep;
>> + struct resource *res;
>> + int ret;
>> +
>> + ep = &pci->ep;
>> + ep->ops = &pcie_ep_ops;
>> +
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
>> + if (!res)
>> + return -EINVAL;
>> +
>> + ep->phys_base = res->start;
>> + ep->addr_size = resource_size(res);
>> +
>> + ret = dw_pcie_ep_init(ep);
>> + if (ret) {
>> + dev_err(dev, "failed to initialize endpoint\n");
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int __init ls_pcie_ep_probe(struct platform_device *pdev) {
>> + struct device *dev = &pdev->dev;
>> + struct dw_pcie *pci;
>> + struct ls_pcie_ep *pcie;
>> + struct resource *dbi_base;
>> + int ret;
>> +
>> + pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>> + if (!pcie)
>> + return -ENOMEM;
>> +
>> + pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
>> + if (!pci)
>> + return -ENOMEM;
>> +
>> + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
>> + if (IS_ERR(pci->dbi_base))
>> + return PTR_ERR(pci->dbi_base);
>> +
>> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
>> + pci->dev = dev;
>> + pci->ops = &ls_pcie_ep_ops;
>> + pcie->pci = pci;
>> +
>> + if (ls_pcie_is_bridge(pcie))
>> + return -ENODEV;
>
> For an endpoint this condition should never occur. This should only mean, a wrong compatible has been used in dt.
> [Xiaowei Bao] This function is a way that can check the PCI controller whether work in EP mode, I think it is more safer. Of course, it can be removed.
> [Xiaowei Bao] Hi Kishon, is there any advice?
IMHO this check is not required.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/64s: Guarded Userspace Access Prevention
From: Russell Currey @ 2018-10-31 4:00 UTC (permalink / raw)
To: LEROY Christophe; +Cc: mikey, linuxppc-dev, npiggin
In-Reply-To: <20181028185706.Horde.lU9x8hQG5ISmBGg3l1SFdw1@messagerie.si.c-s.fr>
On Sun, 2018-10-28 at 18:57 +0100, LEROY Christophe wrote:
> Russell Currey <ruscur@russell.cc> a écrit :
>
> > Guarded Userspace Access Prevention (GUAP) utilises a feature of
> > the Radix MMU which disallows read and write access to userspace
> > addresses. By utilising this, the kernel is prevented from
> > accessing
> > user data from outside of trusted paths that perform proper safety
> > checks,
> > such as copy_{to/from}_user() and friends.
> >
> > Userspace access is disabled from early boot and is only enabled
> > when:
> >
> > - exiting the kernel and entering userspace
> > - performing an operation like copy_{to/from}_user()
> > - context switching to a process that has access enabled
> >
> > and similarly, access is disabled again when exiting userspace and
> > entering
> > the kernel.
> >
> > This feature has a slight performance impact which I roughly
> > measured to be
> > 3% slower in the worst case (performing 1GB of 1 byte
> > read()/write()
> > syscalls), and is gated behind the CONFIG_PPC_RADIX_GUAP option for
> > performance-critical builds.
> >
> > This feature can be tested by using the lkdtm driver
> > (CONFIG_LKDTM=y) and
> > performing the following:
> >
> > echo ACCESS_USERSPACE > [debugfs]/provoke-crash/DIRECT
> >
> > if enabled, this should send SIGSEGV to the thread.
> >
> > Signed-off-by: Russell Currey <ruscur@russell.cc>
>
> I think this patch should be split in at least two parts:
> First part for implementing the generic part, including the changes
> to
> futex and csum, and a second part implementing the radix part.
I'll see how I go making generic handlers - I am concerned about the
implementation becoming more complex than it needs to be just to
accommodate potential future changes that could end up having different
requirements anyway, rather than something simple that works today.
> > ---
> > Since the previous version of this patchset (named KHRAP) there
> > have been
> > several changes, some of which include:
> >
> > - macro naming, suggested by Nick
> > - builds should be fixed outside of 64s
> > - no longer unlock heading out to userspace
> > - removal of unnecessary isyncs
> > - more config option testing
> > - removal of save/restore
> > - use pr_crit() and reword message on fault
> >
> > arch/powerpc/include/asm/exception-64e.h | 3 ++
> > arch/powerpc/include/asm/exception-64s.h | 19 +++++++-
> > arch/powerpc/include/asm/mmu.h | 7 +++
> > arch/powerpc/include/asm/paca.h | 3 ++
> > arch/powerpc/include/asm/reg.h | 1 +
> > arch/powerpc/include/asm/uaccess.h | 57
> > ++++++++++++++++++++----
> > arch/powerpc/kernel/asm-offsets.c | 1 +
> > arch/powerpc/kernel/dt_cpu_ftrs.c | 4 ++
> > arch/powerpc/kernel/entry_64.S | 17 ++++++-
> > arch/powerpc/mm/fault.c | 12 +++++
> > arch/powerpc/mm/pgtable-radix.c | 2 +
> > arch/powerpc/mm/pkeys.c | 7 ++-
> > arch/powerpc/platforms/Kconfig.cputype | 15 +++++++
> > 13 files changed, 135 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/exception-64e.h
> > b/arch/powerpc/include/asm/exception-64e.h
> > index 555e22d5e07f..bf25015834ee 100644
> > --- a/arch/powerpc/include/asm/exception-64e.h
> > +++ b/arch/powerpc/include/asm/exception-64e.h
> > @@ -215,5 +215,8 @@ exc_##label##_book3e:
> > #define RFI_TO_USER
> > \
> > rfi
> >
> > +#define UNLOCK_USER_ACCESS(reg)
> > +#define LOCK_USER_ACCESS(reg)
> > +
> > #endif /* _ASM_POWERPC_EXCEPTION_64E_H */
> >
> > diff --git a/arch/powerpc/include/asm/exception-64s.h
> > b/arch/powerpc/include/asm/exception-64s.h
> > index 3b4767ed3ec5..0cac5bd380ca 100644
> > --- a/arch/powerpc/include/asm/exception-64s.h
> > +++ b/arch/powerpc/include/asm/exception-64s.h
> > @@ -264,6 +264,19 @@ BEGIN_FTR_SECTION_NESTED(943)
> > \
> > std ra,offset(r13); \
> > END_FTR_SECTION_NESTED(ftr,ftr,943)
> >
> > +#define LOCK_USER_ACCESS(reg)
> > \
> > +BEGIN_MMU_FTR_SECTION_NESTED(944)
> > \
> > + LOAD_REG_IMMEDIATE(reg,AMR_LOCKED); \
> > + mtspr SPRN_AMR,reg;
> > \
> > +END_MMU_FTR_SECTION_NESTED(MMU_FTR_RADIX_GUAP,MMU_FTR_RADIX_GUAP,9
> > 44)
> > +
> > +#define UNLOCK_USER_ACCESS(reg)
> > \
> > +BEGIN_MMU_FTR_SECTION_NESTED(945)
> > \
> > + li reg,0; \
> > + mtspr SPRN_AMR,reg;
> > \
> > + isync
> > \
> > +END_MMU_FTR_SECTION_NESTED(MMU_FTR_RADIX_GUAP,MMU_FTR_RADIX_GUAP,9
> > 45)
> > +
> > #define EXCEPTION_PROLOG_0(area)
> > \
> > GET_PACA(r13);
> > \
> > std r9,area+EX_R9(r13); /* save r9 */ \
> > @@ -500,7 +513,11 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
> > beq 4f; /* if from kernel mode */
> > \
> > ACCOUNT_CPU_USER_ENTRY(r13, r9, r10);
> > \
> > SAVE_PPR(area, r9);
> > \
> > -4: EXCEPTION_PROLOG_COMMON_2(area)
> > \
> > +4: lbz r9,PACA_USER_ACCESS_ALLOWED(r13);
> > \
> > + cmpwi cr1,r9,0;
> > \
> > + beq 5f;
> > \
> > + LOCK_USER_ACCESS(r9);
> > \
> > +5: EXCEPTION_PROLOG_COMMON_2(area)
> > \
> > EXCEPTION_PROLOG_COMMON_3(n)
> > \
> > ACCOUNT_STOLEN_TIME
> >
> > diff --git a/arch/powerpc/include/asm/mmu.h
> > b/arch/powerpc/include/asm/mmu.h
> > index eb20eb3b8fb0..3b31ed702785 100644
> > --- a/arch/powerpc/include/asm/mmu.h
> > +++ b/arch/powerpc/include/asm/mmu.h
> > @@ -107,6 +107,10 @@
> > */
> > #define MMU_FTR_1T_SEGMENT ASM_CONST(0x40000000)
> >
> > +/* Supports GUAP (key 0 controlling userspace addresses) on radix
> > + */
> > +#define MMU_FTR_RADIX_GUAP ASM_CONST(0x80000000)
> > +
> > /* MMU feature bit sets for various CPUs */
> > #define MMU_FTRS_DEFAULT_HPTE_ARCH_V2 \
> > MMU_FTR_HPTE_TABLE | MMU_FTR_PPCAS_ARCH_V2
> > @@ -143,6 +147,9 @@ enum {
> > MMU_FTR_KERNEL_RO | MMU_FTR_68_BIT_VA |
> > #ifdef CONFIG_PPC_RADIX_MMU
> > MMU_FTR_TYPE_RADIX |
> > +#endif
> > +#ifdef CONFIG_PPC_RADIX_GUAP
> > + MMU_FTR_RADIX_GUAP |
>
> Can this exist without MMT_FTR_TYPE_RADIX ?
No, no it can't.
>
> > #endif
> > 0,
> > };
> > diff --git a/arch/powerpc/include/asm/paca.h
> > b/arch/powerpc/include/asm/paca.h
> > index e843bc5d1a0f..e905f09b2d38 100644
> > --- a/arch/powerpc/include/asm/paca.h
> > +++ b/arch/powerpc/include/asm/paca.h
> > @@ -169,6 +169,9 @@ struct paca_struct {
> > u64 saved_r1; /* r1 save for RTAS calls
> > or PM or EE=0 */
> > u64 saved_msr; /* MSR saved here by
> > enter_rtas */
> > u16 trap_save; /* Used when bad stack is
> > encountered */
> > +#ifdef CONFIG_PPC_RADIX_GUAP
> > + u8 user_access_allowed; /* set when AMR allows user
> > accesses */
> > +#endif
> > u8 irq_soft_mask; /* mask for irq soft masking */
> > u8 irq_happened; /* irq happened while soft-disabled
> > */
> > u8 io_sync; /* writel() needs spin_unlock sync
> > */
> > diff --git a/arch/powerpc/include/asm/reg.h
> > b/arch/powerpc/include/asm/reg.h
> > index 640a4d818772..b994099a906b 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -246,6 +246,7 @@
> > #define SPRN_DSCR 0x11
> > #define SPRN_CFAR 0x1c /* Come From Address Register */
> > #define SPRN_AMR 0x1d /* Authority Mask Register */
> > +#define AMR_LOCKED 0xC000000000000000ULL /* Read & Write
> > disabled */
>
> Why ULL ? mtspr() takes unsigned long arg.
>
> > #define SPRN_UAMOR 0x9d /* User Authority Mask Override
> > Register */
> > #define SPRN_AMOR 0x15d /* Authority Mask Override Register
> > */
> > #define SPRN_ACOP 0x1F /* Available Coprocessor Register
> > */
> > diff --git a/arch/powerpc/include/asm/uaccess.h
> > b/arch/powerpc/include/asm/uaccess.h
> > index 15bea9a0f260..209bfc47c340 100644
> > --- a/arch/powerpc/include/asm/uaccess.h
> > +++ b/arch/powerpc/include/asm/uaccess.h
> > @@ -62,6 +62,27 @@ static inline int __access_ok(unsigned long
> > addr,
> > unsigned long size,
> >
> > #endif
> >
> > +static inline void unlock_user_access(void)
> > +{
> > +#ifdef CONFIG_PPC_RADIX_GUAP
> > + if (mmu_has_feature(MMU_FTR_RADIX_GUAP)) {
>
> You need to include the .h which provides mmu_has_feature()
>
> I think uaccess.h should only include the empty function for when
> CONFIG_PPC_GUAP is not defined. Radix guap function should go in a
> radix header file.
>
> > + mtspr(SPRN_AMR, 0);
> > + isync();
> > + get_paca()->user_access_allowed = 1;
> > + }
> > +#endif
> > +}
> > +
> > +static inline void lock_user_access(void)
> > +{
> > +#ifdef CONFIG_PPC_RADIX_GUAP
> > + if (mmu_has_feature(MMU_FTR_RADIX_GUAP)) {
> > + mtspr(SPRN_AMR, AMR_LOCKED);
> > + get_paca()->user_access_allowed = 0;
> > + }
> > +#endif
> > +}
> > +
> > #define access_ok(type, addr, size) \
> > (__chk_user_ptr(addr), \
> > __access_ok((__force unsigned long)(addr), (size), get_fs()))
> > @@ -141,6 +162,7 @@ extern long __put_user_bad(void);
> > #define __put_user_size(x, ptr, size, retval)
> > \
> > do {
> > \
> > retval = 0; \
> > + unlock_user_access(); \
> > switch (size) { \
> > case 1: __put_user_asm(x, ptr, retval, "stb"); break; \
> > case 2: __put_user_asm(x, ptr, retval, "sth"); break; \
> > @@ -148,6 +170,7 @@ do {
> > \
> > case 8: __put_user_asm2(x, ptr, retval); break; \
> > default: __put_user_bad(); \
> > } \
> > + lock_user_access(); \
> > } while (0)
> >
> > #define __put_user_nocheck(x, ptr, size) \
> > @@ -240,6 +263,7 @@ do {
> > \
> > __chk_user_ptr(ptr); \
> > if (size > sizeof(x)) \
> > (x) = __get_user_bad(); \
> > + unlock_user_access(); \
> > switch (size) { \
> > case 1: __get_user_asm(x, ptr, retval, "lbz"); break; \
> > case 2: __get_user_asm(x, ptr, retval, "lhz"); break; \
> > @@ -247,6 +271,7 @@ do {
> > \
> > case 8: __get_user_asm2(x, ptr, retval); break; \
> > default: (x) = __get_user_bad(); \
> > } \
> > + lock_user_access(); \
> > } while (0)
> >
> > /*
> > @@ -306,15 +331,20 @@ extern unsigned long
> > __copy_tofrom_user(void
> > __user *to,
> > static inline unsigned long
> > raw_copy_in_user(void __user *to, const void __user *from,
> > unsigned long n)
> > {
> > - return __copy_tofrom_user(to, from, n);
> > + unsigned long ret;
> > + unlock_user_access(); \
> > + ret = __copy_tofrom_user(to, from, n); \
> > + lock_user_access(); \
> > + return ret; \
> > }
> > #endif /* __powerpc64__ */
> >
> > static inline unsigned long raw_copy_from_user(void *to,
> > const void __user *from, unsigned long n)
> > {
> > + unsigned long ret;
> > if (__builtin_constant_p(n) && (n <= 8)) {
> > - unsigned long ret = 1;
> > + ret = 1;
> >
> > switch (n) {
> > case 1:
> > @@ -339,14 +369,18 @@ static inline unsigned long
> > raw_copy_from_user(void *to,
> > }
> >
> > barrier_nospec();
> > - return __copy_tofrom_user((__force void __user *)to, from, n);
> > + unlock_user_access();
> > + ret = __copy_tofrom_user((__force void __user *)to, from, n);
> > + lock_user_access();
> > + return ret;
> > }
> >
> > static inline unsigned long raw_copy_to_user(void __user *to,
> > const void *from, unsigned long n)
> > {
> > + unsigned long ret;
> > if (__builtin_constant_p(n) && (n <= 8)) {
> > - unsigned long ret = 1;
> > + ret = 1;
> >
> > switch (n) {
> > case 1:
> > @@ -366,17 +400,24 @@ static inline unsigned long
> > raw_copy_to_user(void __user *to,
> > return 0;
> > }
> >
> > - return __copy_tofrom_user(to, (__force const void __user
> > *)from, n);
> > + unlock_user_access();
> > + ret = __copy_tofrom_user(to, (__force const void __user *)from,
> > n);
> > + lock_user_access();
> > + return ret;
> > }
> >
> > extern unsigned long __clear_user(void __user *addr, unsigned long
> > size);
> >
> > static inline unsigned long clear_user(void __user *addr,
> > unsigned
> > long size)
> > {
> > + unsigned long ret = size;
> > might_fault();
> > - if (likely(access_ok(VERIFY_WRITE, addr, size)))
> > - return __clear_user(addr, size);
> > - return size;
> > + if (likely(access_ok(VERIFY_WRITE, addr, size))) {
> > + unlock_user_access();
> > + ret = __clear_user(addr, size);
> > + lock_user_access();
> > + }
> > + return ret;
> > }
> >
> > extern long strncpy_from_user(char *dst, const char __user *src,
> > long count);
> > diff --git a/arch/powerpc/kernel/asm-offsets.c
> > b/arch/powerpc/kernel/asm-offsets.c
> > index 10ef2e4db2fd..5050f15ad2f5 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -260,6 +260,7 @@ int main(void)
> > OFFSET(ACCOUNT_STARTTIME_USER, paca_struct,
> > accounting.starttime_user);
> > OFFSET(ACCOUNT_USER_TIME, paca_struct, accounting.utime);
> > OFFSET(ACCOUNT_SYSTEM_TIME, paca_struct, accounting.stime);
> > + OFFSET(PACA_USER_ACCESS_ALLOWED, paca_struct,
> > user_access_allowed);
> > OFFSET(PACA_TRAP_SAVE, paca_struct, trap_save);
> > OFFSET(PACA_NAPSTATELOST, paca_struct, nap_state_lost);
> > OFFSET(PACA_SPRG_VDSO, paca_struct, sprg_vdso);
> > diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
> > b/arch/powerpc/kernel/dt_cpu_ftrs.c
> > index f432054234a4..df4716624840 100644
> > --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
> > +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
> > @@ -337,6 +337,10 @@ static int __init
> > feat_enable_mmu_radix(struct
> > dt_cpu_feature *f)
> > cur_cpu_spec->mmu_features |= MMU_FTRS_HASH_BASE;
> > cur_cpu_spec->cpu_user_features |= PPC_FEATURE_HAS_MMU;
> >
> > +#ifdef CONFIG_PPC_RADIX_GUAP
> > + cur_cpu_spec->mmu_features |= MMU_FTR_RADIX_GUAP;
> > +#endif
> > +
> > return 1;
> > #endif
> > return 0;
> > diff --git a/arch/powerpc/kernel/entry_64.S
> > b/arch/powerpc/kernel/entry_64.S
> > index 7b1693adff2a..23f0944185d3 100644
> > --- a/arch/powerpc/kernel/entry_64.S
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -297,7 +297,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> > b . /* prevent speculative execution */
> >
> > /* exit to kernel */
> > -1: ld r2,GPR2(r1)
> > +1: /* if the AMR was unlocked before, unlock it again */
> > + lbz r2,PACA_USER_ACCESS_ALLOWED(r13)
> > + cmpwi cr1,0
> > + bne 2f
> > + UNLOCK_USER_ACCESS(r2)
> > +2: ld r2,GPR2(r1)
> > ld r1,GPR1(r1)
> > mtlr r4
> > mtcr r5
> > @@ -965,6 +970,7 @@ BEGIN_FTR_SECTION
> > ld r2,_PPR(r1)
> > mtspr SPRN_PPR,r2
> > END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> > +
> > ACCOUNT_CPU_USER_EXIT(r13, r2, r4)
> > REST_GPR(13, r1)
> >
> > @@ -983,7 +989,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> > RFI_TO_USER
> > b . /* prevent speculative execution */
> >
> > -1: mtspr SPRN_SRR1,r3
> > +1: /* exit to kernel */
> > + /* if the AMR was unlocked before, unlock it again */
> > + lbz r2,PACA_USER_ACCESS_ALLOWED(r13)
> > + cmpwi cr1,0
> > + bne 2f
> > + UNLOCK_USER_ACCESS(r2)
> > +
> > +2: mtspr SPRN_SRR1,r3
> >
> > ld r2,_CCR(r1)
> > mtcrf 0xFF,r2
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index d51cf5f4e45e..17fd8c6b055b 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -462,6 +462,18 @@ static int __do_page_fault(struct pt_regs
> > *regs, unsigned long address,
> > return bad_key_fault_exception(regs, address,
> > get_mm_addr_key(mm,
> > address));
> >
> > +#ifdef CONFIG_PPC_RADIX_SMAP
>
> SMAP ?
Whoops, leftover. Good catch.
>
> > + if (mmu_has_feature(MMU_FTR_RADIX_GUAP)) {
> > + if (unlikely(!is_user &&
> > + (error_code & DSISR_PROTFAULT) &&
> > + (mfspr(SPRN_AMR) & AMR_LOCKED))) {
>
> Do you mean that in case of fault in user copy, we leave the
> protection open for handling the exception ? What is the purpose of
> the new paca flag then ?
No. The protection doesn't get left open for handling the exception -
in fact the opposite, the protection gets enforced again on entry. The
PACA flag is to make sure that on exception exit we unlock the AMR on
the way back out during usercopy, without it there is no way of knowing
whether we're supposed to go back to the kernel locked or unlocked.
>
> > + pr_crit("Kernel attempted to access user data"
> > + " unsafely, possible exploit
> > attempt\n");
> > + return bad_area_nosemaphore(regs, address);
> > + }
> > + }
>
> Are we sure it is an access to user data ?
No, this condition could in theory be hit by another kind of PROTFAULT
hit in the kernel. I haven't seen that happen, but I should try
checking the address or something.
>
> > +#endif
> > +
> > /*
> > * We want to do this outside mmap_sem, because reading code
> > around nip
> > * can result in fault, which will cause a deadlock when called
> > with
> > diff --git a/arch/powerpc/mm/pgtable-radix.c
> > b/arch/powerpc/mm/pgtable-radix.c
> > index c879979faa73..9e5b98887a05 100644
> > --- a/arch/powerpc/mm/pgtable-radix.c
> > +++ b/arch/powerpc/mm/pgtable-radix.c
> > @@ -29,6 +29,7 @@
> > #include <asm/powernv.h>
> > #include <asm/sections.h>
> > #include <asm/trace.h>
> > +#include <asm/uaccess.h>
> >
> > #include <trace/events/thp.h>
> >
> > @@ -608,6 +609,7 @@ void __init radix__early_init_mmu(void)
> > mtspr(SPRN_LPCR, lpcr | LPCR_UPRT | LPCR_HR);
> > radix_init_partition_table();
> > radix_init_amor();
> > + lock_user_access();
> > } else {
> > radix_init_pseries();
> > }
> > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> > index b271b283c785..0b9bc320138c 100644
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> > @@ -7,6 +7,7 @@
> >
> > #include <asm/mman.h>
> > #include <asm/setup.h>
> > +#include <asm/uaccess.h>
> > #include <linux/pkeys.h>
> > #include <linux/of_device.h>
> >
> > @@ -266,7 +267,8 @@ int __arch_set_user_pkey_access(struct
> > task_struct *tsk, int pkey,
> >
> > void thread_pkey_regs_save(struct thread_struct *thread)
> > {
> > - if (static_branch_likely(&pkey_disabled))
> > + if (static_branch_likely(&pkey_disabled) &&
> > + !mmu_has_feature(MMU_FTR_RADIX_GUAP))
> > return;
> >
> > /*
> > @@ -280,7 +282,8 @@ void thread_pkey_regs_save(struct thread_struct
> > *thread)
> > void thread_pkey_regs_restore(struct thread_struct *new_thread,
> > struct thread_struct *old_thread)
> > {
> > - if (static_branch_likely(&pkey_disabled))
> > + if (static_branch_likely(&pkey_disabled) &&
> > + !mmu_has_feature(MMU_FTR_RADIX_GUAP))
> > return;
> >
> > if (old_thread->amr != new_thread->amr)
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype
> > b/arch/powerpc/platforms/Kconfig.cputype
> > index f4e2c5729374..6617d3e415a7 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -351,6 +351,21 @@ config PPC_RADIX_MMU_DEFAULT
> >
> > If you're unsure, say Y.
> >
> > +config PPC_RADIX_GUAP
> > + bool "Guarded Userspace Access Prevention on Radix"
> > + depends on PPC_RADIX_MMU
> > + default y
> > + help
> > + Enable support for Guarded Userspace Access Prevention (GUAP)
> > + when using the Radix MMU. GUAP is a security feature
> > + preventing the kernel from directly accessing userspace data
> > + without going through the proper checks.
> > +
> > + GUAP has a minor performance impact on context switching and
> > can be
> > + disabled at boot time using the "nosmap" kernel command line
> > option.
> > +
> > + If you're unsure, say Y.
> > +
>
> I think this should be a named in a generic way without the radix
> thing.
> Then one day it will be reused by the 8xx
I agree in theory, will have to play with making it more generic.
Thanks for the review.
- Russell
>
> Christophe
>
> > config ARCH_ENABLE_HUGEPAGE_MIGRATION
> > def_bool y
> > depends on PPC_BOOK3S_64 && HUGETLB_PAGE && MIGRATION
> > --
> > 2.19.1
>
>
^ permalink raw reply
* Re: [PATCH 0/5] Guarded Userspace Access Prevention on Radix
From: Russell Currey @ 2018-10-31 3:53 UTC (permalink / raw)
To: LEROY Christophe; +Cc: mikey, linuxppc-dev, npiggin
In-Reply-To: <20181026182916.Horde.8LHYJj4tB_PV5JLEA5Czjw1@messagerie.si.c-s.fr>
On Fri, 2018-10-26 at 18:29 +0200, LEROY Christophe wrote:
> Russell Currey <ruscur@russell.cc> a écrit :
>
> > Guarded Userspace Access Prevention is a security mechanism that
> > prevents
> > the kernel from being able to read and write userspace addresses
> > outside of
> > the allowed paths, most commonly copy_{to/from}_user().
> >
> > At present, the only CPU that supports this is POWER9, and only
> > while using
> > the Radix MMU. Privileged reads and writes cannot access user data
> > when
> > key 0 of the AMR is set. This is described in the "Radix Tree
> > Translation
> > Storage Protection" section of the POWER ISA as of version 3.0.
>
> It is not right that only power9 can support that.
It's true that not only P9 can support it, but there are more
considerations under hash than radix, implementing this for radix is a
first step.
>
> The 8xx has mmu access protection registers which can serve the
> same
> purpose. Today on the 8xx kernel space is group 0 and user space is
> group 1. Group 0 is set to "page defined access permission" in
> MD_AP
> and MI_AP registers, and group 1 is set to "all accesses done with
> supervisor rights". By setting group 1 to "user and supervisor
> interpretation swapped" we can forbid kernel access to user space
> while still allowing user access to it. Then by simply changing
> group
> 1 mode at dedicated places we can lock/unlock kernel access to user
> space.
>
> Could you implement something as generic as possible having that in
> mind for a future patch ?
I don't think anything in this series is particularly problematic in
relation to future work for hash. I am interested in doing a hash
implementation in future too.
- Russell
>
> Christophe
>
> > GUAP code sets key 0 of the AMR (thus disabling accesses of user
> > data)
> > early during boot, and only ever "unlocks" access prior to certain
> > operations, like copy_{to/from}_user(), futex ops, etc. Setting
> > this does
> > not prevent unprivileged access, so userspace can operate fine
> > while access
> > is locked.
> >
> > There is a performance impact, although I don't consider it
> > heavy. Running
> > a worst-case benchmark of a 1GB copy 1 byte at a time (and thus
> > constant
> > read(1) write(1) syscalls), I found enabling GUAP to be 3.5% slower
> > than
> > when disabled. In most cases, the difference is negligible. The
> > main
> > performance impact is the mtspr instruction, which is quite slow.
> >
> > There are a few caveats with this series that could be improved
> > upon in
> > future. Right now there is no saving and restoring of the AMR
> > value -
> > there is no userspace exploitation of the AMR on Radix in POWER9,
> > but if
> > this were to change in future, saving and restoring the value would
> > be
> > necessary.
> >
> > No attempt to optimise cases of repeated calls - for example, if
> > some
> > code was repeatedly calling copy_to_user() for small sizes very
> > frequently,
> > it would be slower than the equivalent of wrapping that code in an
> > unlock
> > and lock and only having to modify the AMR once.
> >
> > There are some interesting cases that I've attempted to handle,
> > such as if
> > the AMR is unlocked (i.e. because a copy_{to_from}_user is in
> > progress)...
> >
> > - and an exception is taken, the kernel would then be running
> > with the
> > AMR unlocked and freely able to access userspace again. I am
> > working
> > around this by storing a flag in the PACA to indicate if the
> > AMR is
> > unlocked (to save a costly SPR read), and if so, locking the
> > AMR in
> > the exception entry path and unlocking it on the way out.
> >
> > - and gets context switched out, goes into a path that locks
> > the AMR,
> > then context switches back, access will be disabled and will
> > fault.
> > As a result, I context switch the AMR between tasks as if it
> > was used
> > by userspace like hash (which already implements this).
> >
> > Another consideration is use of the isync instruction. Without an
> > isync
> > following the mtspr instruction, there is no guarantee that the
> > change
> > takes effect. The issue is that isync is very slow, and so I tried
> > to
> > avoid them wherever necessary. In this series, the only place an
> > isync
> > gets used is after *unlocking* the AMR, because if an access takes
> > place
> > and access is still prevented, the kernel will fault.
> >
> > On the flipside, a slight delay in unlocking caused by skipping an
> > isync
> > potentially allows a small window of vulnerability. It is my
> > opinion
> > that this window is practically impossible to exploit, but if
> > someone
> > thinks otherwise, please do share.
> >
> > This series is my first attempt at POWER assembly so all feedback
> > is very
> > welcome.
> >
> > The official theme song of this series can be found here:
> > https://www.youtube.com/watch?v=QjTrnKAcYjE
> >
> > Russell Currey (5):
> > powerpc/64s: Guarded Userspace Access Prevention
> > powerpc/futex: GUAP support for futex ops
> > powerpc/lib: checksum GUAP support
> > powerpc/64s: Disable GUAP with nosmap option
> > powerpc/64s: Document that PPC supports nosmap
> >
> > .../admin-guide/kernel-parameters.txt | 2 +-
> > arch/powerpc/include/asm/exception-64e.h | 3 +
> > arch/powerpc/include/asm/exception-64s.h | 19 ++++++-
> > arch/powerpc/include/asm/futex.h | 6 ++
> > arch/powerpc/include/asm/mmu.h | 7 +++
> > arch/powerpc/include/asm/paca.h | 3 +
> > arch/powerpc/include/asm/reg.h | 1 +
> > arch/powerpc/include/asm/uaccess.h | 57
> > ++++++++++++++++---
> > arch/powerpc/kernel/asm-offsets.c | 1 +
> > arch/powerpc/kernel/dt_cpu_ftrs.c | 4 ++
> > arch/powerpc/kernel/entry_64.S | 17 +++++-
> > arch/powerpc/lib/checksum_wrappers.c | 6 +-
> > arch/powerpc/mm/fault.c | 9 +++
> > arch/powerpc/mm/init_64.c | 15 +++++
> > arch/powerpc/mm/pgtable-radix.c | 2 +
> > arch/powerpc/mm/pkeys.c | 7 ++-
> > arch/powerpc/platforms/Kconfig.cputype | 15 +++++
> > 17 files changed, 158 insertions(+), 16 deletions(-)
> >
> > --
> > 2.19.1
>
>
^ permalink raw reply
* [PATCH] raid6/ppc: Fix build for clang
From: Joel Stanley @ 2018-10-31 3:28 UTC (permalink / raw)
To: Michael Ellerman, linux-kernel, linuxppc-dev
Cc: Jinsong Ji, Nick Desaulniers, Kees Cook, Arnd Bergmann
We cannot build these files with clang as it does not allow altivec
instructions in assembly when -msoft-float is passed.
Jinsong Ji <jji@us.ibm.com> wrote:
> We currently disable Altivec/VSX support when enabling soft-float. So
> any usage of vector builtins will break.
>
> Enable Altivec/VSX with soft-float may need quite some clean up work, so
> I guess this is currently a limitation.
>
> Removing -msoft-float will make it work (and we are lucky that no
> floating point instructions will be generated as well).
This is a workaround until the issue is resolved in clang.
Link: https://bugs.llvm.org/show_bug.cgi?id=31177
Link: https://github.com/ClangBuiltLinux/linux/issues/239
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
lib/raid6/Makefile | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 2f8b61dfd9b0..3a844e6fd01c 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -18,6 +18,21 @@ quiet_cmd_unroll = UNROLL $@
ifeq ($(CONFIG_ALTIVEC),y)
altivec_flags := -maltivec $(call cc-option,-mabi=altivec)
+
+ifdef CONFIG_CC_IS_CLANG
+# clang ppc port does not yet support -maltifec when -msoft-float is
+# enabled. A future release of clang will resolve this
+# https://bugs.llvm.org/show_bug.cgi?id=31177
+CFLAGS_REMOVE_altivec1.o += -msoft-float
+CFLAGS_REMOVE_altivec2.o += -msoft-float
+CFLAGS_REMOVE_altivec4.o += -msoft-float
+CFLAGS_REMOVE_altivec8.o += -msoft-float
+CFLAGS_REMOVE_altivec8.o += -msoft-float
+CFLAGS_REMOVE_vpermxor1.o += -msoft-float
+CFLAGS_REMOVE_vpermxor2.o += -msoft-float
+CFLAGS_REMOVE_vpermxor4.o += -msoft-float
+CFLAGS_REMOVE_vpermxor8.o += -msoft-float
+endif
endif
# The GCC option -ffreestanding is required in order to compile code containing
--
2.19.1
^ permalink raw reply related
* RE: [PATCH 5/6] pci: layerscape: Add the EP mode support.
From: Xiaowei Bao @ 2018-10-31 2:33 UTC (permalink / raw)
To: Kishon Vijay Abraham I, bhelgaas@google.com, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, Leo Li,
lorenzo.pieralisi@arm.com, arnd@arndb.de,
gregkh@linuxfoundation.org, M.h. Lian, Mingkai Hu, Roy Zang,
kstewart@linuxfoundation.org, cyrille.pitchen@free-electrons.com,
pombredanne@nexb.com, shawn.lin@rock-chips.com,
niklas.cassel@axis.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Cc: Jiafei Pan
In-Reply-To: <HE1PR04MB1497DF7D9428A5C791CB6A03F5F00@HE1PR04MB1497.eurprd04.prod.outlook.com>
-----Original Message-----
From: Xiaowei Bao
Sent: 2018年10月26日 17:19
To: 'Kishon Vijay Abraham I' <kishon@ti.com>; bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org; cyrille.pitchen@free-electrons.com; pombredanne@nexb.com; shawn.lin@rock-chips.com; niklas.cassel@axis.com; linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
Cc: Jiafei Pan <jiafei.pan@nxp.com>
Subject: RE: [PATCH 5/6] pci: layerscape: Add the EP mode support.
-----Original Message-----
From: Kishon Vijay Abraham I <kishon@ti.com>
Sent: 2018年10月26日 13:29
To: Xiaowei Bao <xiaowei.bao@nxp.com>; bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org; cyrille.pitchen@free-electrons.com; pombredanne@nexb.com; shawn.lin@rock-chips.com; niklas.cassel@axis.com; linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6] pci: layerscape: Add the EP mode support.
Hi,
On Thursday 25 October 2018 04:39 PM, Xiaowei Bao wrote:
> Add the PCIe EP mode support for layerscape platform.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/dwc/Makefile | 2 +-
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 161
> ++++++++++++++++++++++++
> 2 files changed, 162 insertions(+), 1 deletions(-) create mode
> 100644 drivers/pci/controller/dwc/pci-layerscape-ep.c
>
> diff --git a/drivers/pci/controller/dwc/Makefile
> b/drivers/pci/controller/dwc/Makefile
> index 5d2ce72..b26d617 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -8,7 +8,7 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
> -obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> +obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
> obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o diff --git
> a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> new file mode 100644
> index 0000000..3b33bbc
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe controller EP driver for Freescale Layerscape SoCs
> + *
> + * Copyright (C) 2018 NXP Semiconductor.
> + *
> + * Author: Xiaowei Bao <xiaowei.bao@nxp.com> */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +
> +#include "pcie-designware.h"
> +
> +#define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
The base address should come from dt.
> +
> +struct ls_pcie_ep {
> + struct dw_pcie *pci;
> +};
> +
> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> +
> +static bool ls_pcie_is_bridge(struct ls_pcie_ep *pcie) {
> + struct dw_pcie *pci = pcie->pci;
> + u32 header_type;
> +
> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> + header_type &= 0x7f;
> +
> + return header_type == PCI_HEADER_TYPE_BRIDGE; }
> +
> +static int ls_pcie_establish_link(struct dw_pcie *pci) {
> + return 0;
> +}
There should be some way by which EP should tell RC that it is not configured yet. Are there no bits to control LTSSM state initialization or Configuration retry status enabling?
[Xiaowei Bao] There have not bits to control LTSSM state to tell the RC it is configured. The start link is auto completed.
[Xiaowei Bao] Hi Kishon, is there any advice?
> +
> +static const struct dw_pcie_ops ls_pcie_ep_ops = {
> + .start_link = ls_pcie_establish_link, };
> +
> +static const struct of_device_id ls_pcie_ep_of_match[] = {
> + { .compatible = "fsl,ls-pcie-ep",},
> + { },
> +};
> +
> +static void ls_pcie_ep_init(struct dw_pcie_ep *ep) {
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct pci_epc *epc = ep->epc;
> + enum pci_barno bar;
> +
> + for (bar = BAR_0; bar <= BAR_5; bar++)
> + dw_pcie_ep_reset_bar(pci, bar);
> +
> + epc->features |= EPC_FEATURE_NO_LINKUP_NOTIFIER; }
> +
> +static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> + enum pci_epc_irq_type type, u16 interrupt_num) {
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> +
> + switch (type) {
> + case PCI_EPC_IRQ_LEGACY:
> + return dw_pcie_ep_raise_legacy_irq(ep, func_no);
> + case PCI_EPC_IRQ_MSI:
> + return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
> + case PCI_EPC_IRQ_MSIX:
> + return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
> + default:
> + dev_err(pci->dev, "UNKNOWN IRQ type\n");
> + }
> +
> + return 0;
> +}
> +
> +static struct dw_pcie_ep_ops pcie_ep_ops = {
> + .ep_init = ls_pcie_ep_init,
> + .raise_irq = ls_pcie_ep_raise_irq,
> +};
> +
> +static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> + struct platform_device *pdev)
> +{
> + struct dw_pcie *pci = pcie->pci;
> + struct device *dev = pci->dev;
> + struct dw_pcie_ep *ep;
> + struct resource *res;
> + int ret;
> +
> + ep = &pci->ep;
> + ep->ops = &pcie_ep_ops;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
> + if (!res)
> + return -EINVAL;
> +
> + ep->phys_base = res->start;
> + ep->addr_size = resource_size(res);
> +
> + ret = dw_pcie_ep_init(ep);
> + if (ret) {
> + dev_err(dev, "failed to initialize endpoint\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init ls_pcie_ep_probe(struct platform_device *pdev) {
> + struct device *dev = &pdev->dev;
> + struct dw_pcie *pci;
> + struct ls_pcie_ep *pcie;
> + struct resource *dbi_base;
> + int ret;
> +
> + pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> + if (!pcie)
> + return -ENOMEM;
> +
> + pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> + if (!pci)
> + return -ENOMEM;
> +
> + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> + if (IS_ERR(pci->dbi_base))
> + return PTR_ERR(pci->dbi_base);
> +
> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> + pci->dev = dev;
> + pci->ops = &ls_pcie_ep_ops;
> + pcie->pci = pci;
> +
> + if (ls_pcie_is_bridge(pcie))
> + return -ENODEV;
For an endpoint this condition should never occur. This should only mean, a wrong compatible has been used in dt.
[Xiaowei Bao] This function is a way that can check the PCI controller whether work in EP mode, I think it is more safer. Of course, it can be removed.
[Xiaowei Bao] Hi Kishon, is there any advice?
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
From: kbuild test robot @ 2018-10-31 1:51 UTC (permalink / raw)
To: Douglas Anderson
Cc: Kate Stewart, linux-mips, Rich Felker, linux-sh, Peter Zijlstra,
Catalin Marinas, Will Deacon, linux-kernel, Paul Mackerras,
Daniel Thompson, Yoshinori Sato, linux-hexagon, Russell King,
kgdb-bugreport, James Hogan, linux-snps-arc, Jason Wessel,
Greg Kroah-Hartman, Thomas Gleixner, linux-arm-kernel,
Vineet Gupta, Douglas Anderson, Ralf Baechle, Richard Kuo,
Paul Burton, kbuild-all, Philippe Ombredanne, linuxppc-dev
In-Reply-To: <20181030221843.121254-3-dianders@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 12325 bytes --]
Hi Douglas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kgdb/kgdb-next]
[also build test WARNING on v4.19 next-20181030]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Douglas-Anderson/kgdb-Fix-kgdb_roundup_cpus/20181031-063733
base: https://git.kernel.org/pub/scm/linux/kernel/git/jwessel/kgdb.git kgdb-next
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org)
include/linux/srcu.h:175: warning: Function parameter or member 'p' not described in 'srcu_dereference_notrace'
include/linux/srcu.h:175: warning: Function parameter or member 'sp' not described in 'srcu_dereference_notrace'
include/linux/gfp.h:1: warning: no structured comments found
>> include/linux/kgdb.h:188: warning: Function parameter or member 'ignored' not described in 'kgdb_call_nmi_hook'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev'
include/net/cfg80211.h:4381: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
include/net/cfg80211.h:4869: warning: Excess function parameter 'ptr' description in 'reg_query_regdb_wmm'
vim +188 include/linux/kgdb.h
> 188
189
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6570 bytes --]
^ permalink raw reply
* [PATCH] powerpc/xmon: Relax frame size for clang
From: Joel Stanley @ 2018-10-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Naveen N . Rao, linuxppc-dev; +Cc: Nick Desaulniers
When building with clang (8 trunk, 7.0 release) the frame size limit is
hit:
arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576
bytes in function 'xmon_core' [-Wframe-larger-than=]
Some investigation by Naveen indicates this is due to clang saving the
addresses to printf format strings on the stack.
While this issue is investigated, bump up the frame size limit for xmon
when building with clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/252
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/powerpc/xmon/Makefile | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 69e7fb47bcaa..878f9c1d3615 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -11,6 +11,12 @@ UBSAN_SANITIZE := n
ORIG_CFLAGS := $(KBUILD_CFLAGS)
KBUILD_CFLAGS = $(subst $(CC_FLAGS_FTRACE),,$(ORIG_CFLAGS))
+ifdef CONFIG_CC_IS_CLANG
+# clang stores addresses on the stack causing the frame size to blow
+# out. See https://github.com/ClangBuiltLinux/linux/issues/252
+KBUILD_CFLAGS += -Wframe-larger-than=4096
+endif
+
ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
obj-y += xmon.o nonstdio.o spr_access.o
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 2/2] selftests/powerpc: Skip test instead of failing
From: Tyrel Datwyler @ 2018-10-31 0:09 UTC (permalink / raw)
To: Michael Ellerman, Thiago Jung Bauermann, Breno Leitao
Cc: linuxppc-dev, Tyrel Datwyler
In-Reply-To: <87r2g7ihwi.fsf@concordia.ellerman.id.au>
On 10/30/2018 08:16 AM, Michael Ellerman wrote:
> Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
>
>> Breno Leitao <leitao@debian.org> writes:
>>
>>> Hi Tyrel,
>>>
>>> On 10/23/2018 05:41 PM, Tyrel Datwyler wrote:
>>>>> --- a/tools/testing/selftests/powerpc/ptrace/core-pkey.c
>>>>> +++ b/tools/testing/selftests/powerpc/ptrace/core-pkey.c
>>>>> @@ -352,17 +352,11 @@ static int write_core_pattern(const char *core_pattern)
>>>>> FILE *f;
>>>>>
>>>>> f = fopen(core_pattern_file, "w");
>>>>> - if (!f) {
>>>>> - perror("Error writing to core_pattern file");
>>>>> - return TEST_FAIL;
>>>>> - }
>>>>> + SKIP_IF(!f);
>>>>>
>>>>> ret = fwrite(core_pattern, 1, len, f);
>>>>> fclose(f);
>>>>> - if (ret != len) {
>>>>> - perror("Error writing to core_pattern file");
>>>>> - return TEST_FAIL;
>>>>> - }
>>>>> + SKIP_IF(ret != len);
>>>
>>>> If we don't have proper privileges we should fail on the open, right?
>>>> So wouldn't we still want to fail on the write if something goes
>>>> wrong?
>>>
>>> That is a good point. Should the test fail or skip if it is not possible
>>> to create the infrastructure to run the core test?
>>>
>>> Trying to find the answer in the current test sets, I find tests where
>>> the self test skips if the test environment is not able to be set up, as
>>> for example, when a memory allocation fails.
>>>
>>> File: tools/testing/selftests/powerpc/alignment/alignment_handler.c
>>>
>>> ci1 = mmap(NULL, bufsize, PROT_WRITE, MAP_SHARED,
>>> fd, bufsize);
>>> if ((ci0 == MAP_FAILED) || (ci1 == MAP_FAILED)) {
>>> printf("\n");
>>> perror("mmap failed");
>>> SKIP_IF(1);
>>> }
>>
>> I think TEST_FAIL means the test was able to exercise the feature
>> and found a problem with it. In this case, the test wasn't able to
>> exercise the feature so it's not appropriate.
>>
>> Ideally, there should be a TEST_ERROR result for a case like this where
>> an unexpected problem prevented the testcase from exercising the
>> feature.
>>
>> If we're to use the an existing result then I vote for SKIP_IF.
>
> Yeah I agree.
>
> See for example some of the TM tests, which skip if TM is not available.
> Or the alignment test which skips if it can't open /dev/fb0.
>
> In this case it should print "you need to be root to run this" and then
> skip.
Agreed that there should be some indicator of why we are skipping the test. My original point I was trying to make was that I thought skipping a failed open was okay because we are likely not root. However, I wasn't sure that a failed write was okay to skip as that could be an indicator that something has actually been broken.
-Tyrel
>
> cheers
>
^ permalink raw reply
* Re: [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
From: Doug Anderson @ 2018-10-30 22:20 UTC (permalink / raw)
To: Daniel Thompson
Cc: Nishanth Menon, linux-mips, dalias, vigneshr, linux-aspeed,
linux-sh, Peter Zijlstra, Catalin Marinas, Will Deacon, mhocko,
paulus, H. Peter Anvin, sparclinux, Jiri Slaby, Ingo Molnar,
marex, Stephen Rothwell, ysato, linux-hexagon, x86,
Russell King - ARM Linux, Tony Lindgren, Ingo Molnar, joel,
linux-serial, kgdb-bugreport, jhogan, rolf.evers.fischer, asierra,
linux-snps-arc, Dan Carpenter, ying.huang, Jisheng Zhang, riel,
linux-arm-msm, frederic, pombredanne, rppt, bp, luto,
Thomas Gleixner, Andy Shevchenko, Linux ARM, andrew,
Greg Kroah-Hartman, LKML, Ralf Baechle, rkuo, paul.burton,
Vineet Gupta, Jeremy Kerr, Jason Wessel, Andrew Morton,
linuxppc-dev, David Miller, kstewart
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>
Hi,
On Tue, Oct 30, 2018 at 4:56 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently. The first is a serial series and the second is a
> > kgdb series.
>
> Indeed.
>
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
>
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.
Yes, sorry about the mess. Splitting this into two series makes the
most sense. Then I can focus more on trying to get the CCs right and
people can just get the patches that matter to them.
OK, I've sent v2 of both series out now. Please yell if you can't
find them for whatever reason.
-Doug
-Doug
^ permalink raw reply
* Re: [PATCH 7/7] kgdb: Remove irq flags and local_irq_enable/disable from roundup
From: Doug Anderson @ 2018-10-30 22:22 UTC (permalink / raw)
To: Daniel Thompson
Cc: kstewart, linux-mips, dalias, Catalin Marinas, linux-sh,
Will Deacon, mhocko, paulus, H. Peter Anvin, sparclinux,
linux-hexagon, Ingo Molnar, Stephen Rothwell, ysato, x86,
Russell King - ARM Linux, Ingo Molnar, kgdb-bugreport, jhogan,
linux-snps-arc, linux-arm-msm, ying.huang, rppt, bp,
Thomas Gleixner, Linux ARM, pombredanne, Greg Kroah-Hartman, LKML,
Ralf Baechle, rkuo, paul.burton, Vineet Gupta, Jason Wessel,
Andrew Morton, linuxppc-dev, David Miller
In-Reply-To: <20181030114603.xdvyvayzw2an5c3q@holly.lan>
Hi,
On Tue, Oct 30, 2018 at 4:46 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, Oct 29, 2018 at 11:07:07AM -0700, Douglas Anderson wrote:
> > The function kgdb_roundup_cpus() was passed a parameter that was
> > documented as:
> >
> > > the flags that will be used when restoring the interrupts. There is
> > > local_irq_save() call before kgdb_roundup_cpus().
> >
> > Nobody used those flags. Anyone who wanted to temporarily turn on
> > interrupts just did local_irq_enable() and local_irq_disable() without
> > looking at them. So we can definitely remove the flags.
>
> On the whole I'd rather that this change...
>
>
> > Speaking of calling local_irq_enable(), it seems like a bad idea and
> > it caused a nice splat on my system with lockdep turned on.
> > Specifically it hit:
> > DEBUG_LOCKS_WARN_ON(current->hardirq_context)
>
> ... and fixes for this this were in separate patches. They don't appear
> especially related.
Agreed that this is cleaner. Done for v2.
-Doug
^ permalink raw reply
* Re: [PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
From: Doug Anderson @ 2018-10-30 22:21 UTC (permalink / raw)
To: Daniel Thompson
Cc: linux-mips, linux-sh, Peter Zijlstra, kgdb-bugreport,
linux-arm-msm, Jason Wessel, LKML, frederic, Linux ARM, luto,
Greg Kroah-Hartman, sparclinux, linux-hexagon, Thomas Gleixner,
linux-snps-arc, linuxppc-dev, Ingo Molnar, riel
In-Reply-To: <20181030094159.zt6akmyxwrbzoe2x@holly.lan>
Daniel,
On Tue, Oct 30, 2018 at 2:42 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> > In kgdb_roundup_cpus() we've got code that looks like:
> > local_irq_enable();
> > smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> > local_irq_disable();
> >
> > In certain cases when we drop into kgdb (like with sysrq-g on a serial
> > console) we'll get a big yell that looks like:
> >
> > sysrq: SysRq : DEBUG
> > ------------[ cut here ]------------
> > DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> > WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 lockdep_hardirqs_on+0xf0/0x160
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
> > pstate: 604003c9 (nZCv DAIF +PAN -UAO)
> > pc : lockdep_hardirqs_on+0xf0/0x160
> > ...
> > Call trace:
> > lockdep_hardirqs_on+0xf0/0x160
> > trace_hardirqs_on+0x188/0x1ac
> > kgdb_roundup_cpus+0x14/0x3c
> > kgdb_cpu_enter+0x53c/0x5cc
> > kgdb_handle_exception+0x180/0x1d4
> > kgdb_compiled_brk_fn+0x30/0x3c
> > brk_handler+0x134/0x178
> > do_debug_exception+0xfc/0x178
> > el1_dbg+0x18/0x78
> > kgdb_breakpoint+0x34/0x58
> > sysrq_handle_dbg+0x54/0x5c
> > __handle_sysrq+0x114/0x21c
> > handle_sysrq+0x30/0x3c
> > qcom_geni_serial_isr+0x2dc/0x30c
> > ...
> > ...
> > irq event stamp: ...45
> > hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4
> > hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
> > softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34
> > softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
> > ---[ end trace adf21f830c46e638 ]---
> >
> > Let's add kgdb to the list of reasons not to warn in
> > smp_call_function_many(). That will allow us (in a future patch) to
> > stop calling local_irq_enable() which will get rid of the original
> > splat.
> >
> > NOTE: with this change comes the obvious question: will we start
> > deadlocking more often now when we drop into the debugger. I can't
> > say that for sure one way or the other, but the fact that we do the
> > same logic for "oops_in_progress" makes me feel like it shouldn't
> > happen too often. Also note that the old logic of turning on
> > interrupts temporarily wasn't exactly safe since (I presume) that
> > could have violated spin_lock_irqsave() semantics and ended up with a
> > deadlock of its own.
>
> This is part of the code to bring all the cores to a halt and since
> the other cores are still running kgdb isn't yet able to use the fact
> all the CPUs are halted to bend the rules. It is better for this code
> to play by the rules if it can.
>
> Is is possible to get the roundup functions to use a private csd
> alongside smp_call_function_single_async()? We could add a helper
> function to the debug core to avoid having to add cpu_online loops into
> every kgdb_roundup_cpus() implementaton.
Exactly the kind of helpful suggestion I was looking for. Thank you
very much! See v2 and hopefully it matches what you were thinking of.
-Doug
^ permalink raw reply
* [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
From: Douglas Anderson @ 2018-10-30 22:18 UTC (permalink / raw)
To: Jason Wessel, Daniel Thompson
Cc: Kate Stewart, linux-mips, Rich Felker, linux-sh, Peter Zijlstra,
Catalin Marinas, Will Deacon, linux-kernel, Paul Mackerras,
Yoshinori Sato, linux-hexagon, Russell King, kgdb-bugreport,
James Hogan, linux-snps-arc, Greg Kroah-Hartman, Thomas Gleixner,
linux-arm-kernel, Vineet Gupta, Douglas Anderson, Ralf Baechle,
Richard Kuo, Paul Burton, Philippe Ombredanne, linuxppc-dev
In-Reply-To: <20181030221843.121254-1-dianders@chromium.org>
When I had lockdep turned on and dropped into kgdb I got a nice splat
on my system. Specifically it hit:
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
Specifically it looked like this:
sysrq: SysRq : DEBUG
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 lockdep_hardirqs_on+0xf0/0x160
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
pstate: 604003c9 (nZCv DAIF +PAN -UAO)
pc : lockdep_hardirqs_on+0xf0/0x160
...
Call trace:
lockdep_hardirqs_on+0xf0/0x160
trace_hardirqs_on+0x188/0x1ac
kgdb_roundup_cpus+0x14/0x3c
kgdb_cpu_enter+0x53c/0x5cc
kgdb_handle_exception+0x180/0x1d4
kgdb_compiled_brk_fn+0x30/0x3c
brk_handler+0x134/0x178
do_debug_exception+0xfc/0x178
el1_dbg+0x18/0x78
kgdb_breakpoint+0x34/0x58
sysrq_handle_dbg+0x54/0x5c
__handle_sysrq+0x114/0x21c
handle_sysrq+0x30/0x3c
qcom_geni_serial_isr+0x2dc/0x30c
...
...
irq event stamp: ...45
hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4
hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34
softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
---[ end trace adf21f830c46e638 ]---
Looking closely at it, it seems like a really bad idea to be calling
local_irq_enable() in kgdb_roundup_cpus(). If nothing else that seems
like it could violate spinlock semantics and cause a deadlock.
Instead, let's use a private csd alongside
smp_call_function_single_async() to round up the other CPUs. Using
smp_call_function_single_async() doesn't require interrupts to be
enabled so we can remove the offending bit of code.
In order to avoid duplicating this across all the architectures that
use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
to debug_core.c.
Looking at all the people who previously had copies of this code,
there were a few variants. I've attempted to keep the variants
working like they used to. Specifically:
* For arch/arc we passed NULL to kgdb_nmicallback() instead of
get_irq_regs().
* For arch/mips there was a bit of extra code around
kgdb_nmicallback()
Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).
arch/arc/kernel/kgdb.c | 10 ++--------
arch/arm/kernel/kgdb.c | 12 ------------
arch/arm64/kernel/kgdb.c | 12 ------------
arch/hexagon/kernel/kgdb.c | 27 ---------------------------
arch/mips/kernel/kgdb.c | 9 +--------
arch/powerpc/kernel/kgdb.c | 4 ++--
arch/sh/kernel/kgdb.c | 12 ------------
include/linux/kgdb.h | 15 +++++++++++++--
kernel/debug/debug_core.c | 36 ++++++++++++++++++++++++++++++++++++
9 files changed, 54 insertions(+), 83 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 0932851028e0..68d9fe4b5aa7 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -192,18 +192,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
instruction_pointer(regs) = ip;
}
-static void kgdb_call_nmi_hook(void *ignored)
+void kgdb_call_nmi_hook(void *ignored)
{
+ /* Default implementation passes get_irq_regs() but we don't */
kgdb_nmicallback(raw_smp_processor_id(), NULL);
}
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
struct kgdb_arch arch_kgdb_ops = {
/* breakpoint instruction: TRAP_S 0x3 */
#ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index f21077b077be..d9a69e941463 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -170,18 +170,6 @@ static struct undef_hook kgdb_compiled_brkpt_hook = {
.fn = kgdb_compiled_brk_fn
};
-static void kgdb_call_nmi_hook(void *ignored)
-{
- kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
-}
-
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
{
struct pt_regs *regs = args->regs;
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 12c339ff6e75..da880247c734 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -284,18 +284,6 @@ static struct step_hook kgdb_step_hook = {
.fn = kgdb_step_brk_fn
};
-static void kgdb_call_nmi_hook(void *ignored)
-{
- kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
-}
-
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
{
struct pt_regs *regs = args->regs;
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 012e0e230ac2..b95d12038a4e 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -115,33 +115,6 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
instruction_pointer(regs) = pc;
}
-#ifdef CONFIG_SMP
-
-/**
- * kgdb_roundup_cpus - Get other CPUs into a holding pattern
- *
- * On SMP systems, we need to get the attention of the other CPUs
- * and get them be in a known state. This should do what is needed
- * to get the other CPUs to call kgdb_wait(). Note that on some arches,
- * the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs.
- *
- * On non-SMP systems, this is not called.
- */
-
-static void hexagon_kgdb_nmi_hook(void *ignored)
-{
- kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
-}
-
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-#endif
-
/* Not yet working */
void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs,
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index 2b05effc17b4..42f057a6c215 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -207,7 +207,7 @@ void arch_kgdb_breakpoint(void)
".set\treorder");
}
-static void kgdb_call_nmi_hook(void *ignored)
+void kgdb_call_nmi_hook(void *ignored)
{
mm_segment_t old_fs;
@@ -219,13 +219,6 @@ static void kgdb_call_nmi_hook(void *ignored)
set_fs(old_fs);
}
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
static int compute_signal(int tt)
{
struct hard_trap_info *ht;
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index b0e804844be0..b4ce54d73337 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -117,7 +117,7 @@ int kgdb_skipexception(int exception, struct pt_regs *regs)
return kgdb_isremovedbreak(regs->nip);
}
-static int kgdb_call_nmi_hook(struct pt_regs *regs)
+static int kgdb_debugger_ipi(struct pt_regs *regs)
{
kgdb_nmicallback(raw_smp_processor_id(), regs);
return 0;
@@ -502,7 +502,7 @@ int kgdb_arch_init(void)
old__debugger_break_match = __debugger_break_match;
old__debugger_fault_handler = __debugger_fault_handler;
- __debugger_ipi = kgdb_call_nmi_hook;
+ __debugger_ipi = kgdb_debugger_ipi;
__debugger = kgdb_debugger;
__debugger_bpt = kgdb_handle_breakpoint;
__debugger_sstep = kgdb_singlestep;
diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
index cc57630f6bf2..14e012ad7c57 100644
--- a/arch/sh/kernel/kgdb.c
+++ b/arch/sh/kernel/kgdb.c
@@ -314,18 +314,6 @@ BUILD_TRAP_HANDLER(singlestep)
local_irq_restore(flags);
}
-static void kgdb_call_nmi_hook(void *ignored)
-{
- kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
-}
-
-void kgdb_roundup_cpus(void)
-{
- local_irq_enable();
- smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
-}
-
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
{
int ret;
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 05e5b2eb0d32..f4f866273ed2 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -176,14 +176,25 @@ kgdb_arch_handle_exception(int vector, int signo, int err_code,
char *remcom_out_buffer,
struct pt_regs *regs);
+/**
+ * kgdb_call_nmi_hook - Call kgdb_nmicallback() on the current CPU
+ *
+ * If you're using the default implementation of kgdb_roundup_cpus()
+ * this function will be called per CPU. If you don't implement
+ * kgdb_call_nmi_hook() a default will be used.
+ */
+
+extern void kgdb_call_nmi_hook(void *ignored);
+
+
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them into a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
- * the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs.
+ * the NMI approach is not used for rounding up all the CPUs. Normally
+ * those architectures can just not implement this and get the default.
*
* On non-SMP systems, this is not called.
*/
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index f3cadda45f07..9a3f952de6ed 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -55,6 +55,7 @@
#include <linux/mm.h>
#include <linux/vmacache.h>
#include <linux/rcupdate.h>
+#include <linux/irq.h>
#include <asm/cacheflush.h>
#include <asm/byteorder.h>
@@ -220,6 +221,39 @@ int __weak kgdb_skipexception(int exception, struct pt_regs *regs)
return 0;
}
+/*
+ * Default (weak) implementation for kgdb_roundup_cpus
+ */
+
+static DEFINE_PER_CPU(call_single_data_t, kgdb_roundup_csd);
+
+void __weak kgdb_call_nmi_hook(void *ignored)
+{
+ kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
+}
+
+void __weak kgdb_roundup_cpus(void)
+{
+ call_single_data_t *csd;
+ int cpu;
+
+ for_each_cpu(cpu, cpu_online_mask) {
+ csd = &per_cpu(kgdb_roundup_csd, cpu);
+ smp_call_function_single_async(cpu, csd);
+ }
+}
+
+static void kgdb_generic_roundup_init(void)
+{
+ call_single_data_t *csd;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ csd = &per_cpu(kgdb_roundup_csd, cpu);
+ csd->func = kgdb_call_nmi_hook;
+ }
+}
+
/*
* Some architectures need cache flushes when we set/clear a
* breakpoint:
@@ -993,6 +1027,8 @@ int kgdb_register_io_module(struct kgdb_io *new_dbg_io_ops)
return -EBUSY;
}
+ kgdb_generic_roundup_init();
+
if (new_dbg_io_ops->init) {
err = new_dbg_io_ops->init();
if (err) {
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* [PATCH v2 1/2] kgdb: Remove irq flags from roundup
From: Douglas Anderson @ 2018-10-30 22:18 UTC (permalink / raw)
To: Jason Wessel, Daniel Thompson
Cc: Kate Stewart, linux-mips, Rich Felker, Catalin Marinas, linux-sh,
Peter Zijlstra, kgdb-bugreport, Will Deacon, linux-kernel,
Paul Mackerras, H. Peter Anvin, sparclinux, Yoshinori Sato,
linux-hexagon, x86, Russell King, Ingo Molnar, James Hogan,
linux-snps-arc, Huang Ying, Greg Kroah-Hartman, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Vineet Gupta, Douglas Anderson,
Ralf Baechle, Richard Kuo, Paul Burton, Philippe Ombredanne,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20181030221843.121254-1-dianders@chromium.org>
The function kgdb_roundup_cpus() was passed a parameter that was
documented as:
> the flags that will be used when restoring the interrupts. There is
> local_irq_save() call before kgdb_roundup_cpus().
Nobody used those flags. Anyone who wanted to temporarily turn on
interrupts just did local_irq_enable() and local_irq_disable() without
looking at them. So we can definitely remove the flags.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
arch/arc/kernel/kgdb.c | 2 +-
arch/arm/kernel/kgdb.c | 2 +-
arch/arm64/kernel/kgdb.c | 2 +-
arch/hexagon/kernel/kgdb.c | 9 ++-------
arch/mips/kernel/kgdb.c | 2 +-
arch/powerpc/kernel/kgdb.c | 2 +-
arch/sh/kernel/kgdb.c | 2 +-
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 ++-------
include/linux/kgdb.h | 9 ++-------
kernel/debug/debug_core.c | 2 +-
11 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..0932851028e0 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -197,7 +197,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), NULL);
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..f21077b077be 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -175,7 +175,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..12c339ff6e75 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -289,7 +289,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..012e0e230ac2 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -119,17 +119,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them be in a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
* the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
*
* On non-SMP systems, this is not called.
*/
@@ -139,7 +134,7 @@ static void hexagon_kgdb_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..2b05effc17b4 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -219,7 +219,7 @@ static void kgdb_call_nmi_hook(void *ignored)
set_fs(old_fs);
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 59c578f865aa..b0e804844be0 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -124,7 +124,7 @@ static int kgdb_call_nmi_hook(struct pt_regs *regs)
}
#ifdef CONFIG_SMP
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
smp_send_debugger_break();
}
diff --git a/arch/sh/kernel/kgdb.c b/arch/sh/kernel/kgdb.c
index 4f04c6638a4d..cc57630f6bf2 100644
--- a/arch/sh/kernel/kgdb.c
+++ b/arch/sh/kernel/kgdb.c
@@ -319,7 +319,7 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
index d3ea1f3c06a0..68098bbf3705 100644
--- a/arch/sparc/kernel/smp_64.c
+++ b/arch/sparc/kernel/smp_64.c
@@ -1014,7 +1014,7 @@ void flush_dcache_page_all(struct mm_struct *mm, struct page *page)
}
#ifdef CONFIG_KGDB
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
smp_cross_call(&xcall_kgdb_capture, 0, 0, 0);
}
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 8e36f249646e..ac6291a4178d 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -422,21 +422,16 @@ static void kgdb_disable_hw_debug(struct pt_regs *regs)
#ifdef CONFIG_SMP
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them be in a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
* the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
*
* On non-SMP systems, this is not called.
*/
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
apic->send_IPI_allbutself(APIC_DM_NMI);
}
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index e465bb15912d..05e5b2eb0d32 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -178,21 +178,16 @@ kgdb_arch_handle_exception(int vector, int signo, int err_code,
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them into a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
* the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
*
* On non-SMP systems, this is not called.
*/
-extern void kgdb_roundup_cpus(unsigned long flags);
+extern void kgdb_roundup_cpus(void);
/**
* kgdb_arch_set_pc - Generic call back to the program counter
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 65c0f1363788..f3cadda45f07 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -593,7 +593,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct pt_regs *regs,
/* Signal the other CPUs to enter kgdb_wait() */
else if ((!kgdb_single_step) && kgdb_do_roundup)
- kgdb_roundup_cpus(flags);
+ kgdb_roundup_cpus();
#endif
/*
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* [PATCH v2 0/2] kgdb: Fix kgdb_roundup_cpus()
From: Douglas Anderson @ 2018-10-30 22:18 UTC (permalink / raw)
To: Jason Wessel, Daniel Thompson
Cc: Kate Stewart, linux-mips, Rich Felker, Catalin Marinas, linux-sh,
Peter Zijlstra, kgdb-bugreport, Will Deacon, linux-kernel,
Paul Mackerras, H. Peter Anvin, sparclinux, Yoshinori Sato,
linux-hexagon, x86, Russell King, Ingo Molnar, James Hogan,
linux-snps-arc, Huang Ying, Greg Kroah-Hartman, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Vineet Gupta, Douglas Anderson,
Ralf Baechle, Richard Kuo, Paul Burton, Philippe Ombredanne,
Andrew Morton, linuxppc-dev, David S. Miller
This series was originally part of the series ("serial: Finish kgdb on
qcom_geni; fix many lockdep splats w/ kgdb") but it made sense to
split it up.
It's believed that dropping into kgdb should be more robust once these
patches are applied.
Changes in v2:
- Removing irq flags separated from fixing lockdep splat.
- Don't use smp_call_function (Daniel).
Douglas Anderson (2):
kgdb: Remove irq flags from roundup
kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
arch/arc/kernel/kgdb.c | 10 ++--------
arch/arm/kernel/kgdb.c | 12 ------------
arch/arm64/kernel/kgdb.c | 12 ------------
arch/hexagon/kernel/kgdb.c | 32 --------------------------------
arch/mips/kernel/kgdb.c | 9 +--------
arch/powerpc/kernel/kgdb.c | 6 +++---
arch/sh/kernel/kgdb.c | 12 ------------
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 ++-------
include/linux/kgdb.h | 22 ++++++++++++++--------
kernel/debug/debug_core.c | 38 +++++++++++++++++++++++++++++++++++++-
11 files changed, 60 insertions(+), 104 deletions(-)
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply
* Re: [PATCH v2 1/2] kbuild: replace cc-name test with CONFIG_CC_IS_CLANG
From: Joel Stanley @ 2018-10-30 21:11 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mips, Michal Marek, linux-kbuild, jhogan,
Linux Kernel Mailing List, ralf, paul.burton, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1540905994-6073-1-git-send-email-yamada.masahiro@socionext.com>
On Tue, 30 Oct 2018 at 23:58, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Evaluating cc-name invokes the compiler every time even when you are
> not compiling anything, like 'make help'. This is not efficient.
>
> The compiler type has been already detected in the Kconfig stage.
> Use CONFIG_CC_IS_CLANG, instead.
Thanks, I didn't know about this.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
^ permalink raw reply
* Re: [PATCH] hwmon: (ibmpowernv) Remove bogus __init annotations
From: Guenter Roeck @ 2018-10-30 18:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-hwmon, Jean Delvare, linux-kernel, Cédric Le Goater,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20181028171651.30751-1-geert@linux-m68k.org>
On Sun, Oct 28, 2018 at 06:16:51PM +0100, Geert Uytterhoeven wrote:
> If gcc decides not to inline make_sensor_label():
>
> WARNING: vmlinux.o(.text+0x4df549c): Section mismatch in reference from the function .create_device_attrs() to the function .init.text:.make_sensor_label()
> The function .create_device_attrs() references
> the function __init .make_sensor_label().
> This is often because .create_device_attrs lacks a __init
> annotation or the annotation of .make_sensor_label is wrong.
>
> As .probe() can be called after freeing of __init memory, all __init
> annotiations in the driver are bogus, and should be removed.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied.
Thanks,
Guenter
> ---
> Compile-tested only.
> ---
> drivers/hwmon/ibmpowernv.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 0ccca87f527191dc..293dd1c6c7b36ef2 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -181,7 +181,7 @@ static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
> return sprintf(buf, "%s\n", sdata->label);
> }
>
> -static int __init get_logical_cpu(int hwcpu)
> +static int get_logical_cpu(int hwcpu)
> {
> int cpu;
>
> @@ -192,9 +192,8 @@ static int __init get_logical_cpu(int hwcpu)
> return -ENOENT;
> }
>
> -static void __init make_sensor_label(struct device_node *np,
> - struct sensor_data *sdata,
> - const char *label)
> +static void make_sensor_label(struct device_node *np,
> + struct sensor_data *sdata, const char *label)
> {
> u32 id;
> size_t n;
^ permalink raw reply
* Re: [PATCH v2 1/2] kbuild: replace cc-name test with CONFIG_CC_IS_CLANG
From: Paul Burton @ 2018-10-30 16:51 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mips@linux-mips.org, Michal Marek,
linux-kbuild@vger.kernel.org, James Hogan,
linux-kernel@vger.kernel.org, Ralf Baechle, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1540905994-6073-1-git-send-email-yamada.masahiro@socionext.com>
Hi Masahiro,
On Tue, Oct 30, 2018 at 10:26:33PM +0900, Masahiro Yamada wrote:
> Evaluating cc-name invokes the compiler every time even when you are
> not compiling anything, like 'make help'. This is not efficient.
>
> The compiler type has been already detected in the Kconfig stage.
> Use CONFIG_CC_IS_CLANG, instead.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Looks good to me:
Acked-by: Paul Burton <paul.burton@mips.com> (MIPS)
Thanks,
Paul
^ 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