* [PATCH] powerpc: Fix PPC_EMULATED_STATS build break with sync patch
From: Scott Wood @ 2013-10-29 3:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, James Yang, linuxppc-dev, Kumar Gala
Commit 9863c28a2af90a56c088f5f6288d7f6d2c923c14 ("powerpc: Emulate sync
instruction variants") introduced a build breakage with
CONFIG_PPC_EMULATED_STATS enabled.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Kumar Gala <galak@kernel.org>
Cc: James Yang <James.Yang@freescale.com>
---
---
arch/powerpc/include/asm/emulated_ops.h | 1 +
arch/powerpc/kernel/traps.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/emulated_ops.h b/arch/powerpc/include/asm/emulated_ops.h
index 5a8b82a..4358e30 100644
--- a/arch/powerpc/include/asm/emulated_ops.h
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -43,6 +43,7 @@ extern struct ppc_emulated {
struct ppc_emulated_entry popcntb;
struct ppc_emulated_entry spe;
struct ppc_emulated_entry string;
+ struct ppc_emulated_entry sync;
struct ppc_emulated_entry unaligned;
#ifdef CONFIG_MATH_EMULATION
struct ppc_emulated_entry math;
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index ad20dcf..62c3dd8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1820,6 +1820,7 @@ struct ppc_emulated ppc_emulated = {
WARN_EMULATED_SETUP(popcntb),
WARN_EMULATED_SETUP(spe),
WARN_EMULATED_SETUP(string),
+ WARN_EMULATED_SETUP(sync),
WARN_EMULATED_SETUP(unaligned),
#ifdef CONFIG_MATH_EMULATION
WARN_EMULATED_SETUP(math),
--
1.8.1.2
^ permalink raw reply related
* Re: Pull request: scottwood/linux.git next
From: Scott Wood @ 2013-10-29 3:05 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20131029024412.GA25844@home.buserror.net>
On Mon, 2013-10-28 at 21:44 -0500, Scott Wood wrote:
> Sorry again for the lateness. I tried to get this done before the
> conferences last week, but it just didn't happen.
>
> Highlights include corenet board file consolidation, the ability to run
> userspaces with lwsync on e500v1/v2, some cleanup patches that other KVM
> patches will build on, support for stripped-down e6500 emulation targets,
> and some fixes of minor longstanding issues.
>
> Some of the more complicated and/or more recently posted patches didn't
> make it this time around; this doesn't mean I've forgotten them (as long
> as they're in patchwork in an action required state), just that I've run
> out of time for 3.13.
>
> The following changes since commit 3ad26e5c4459d3793ad65bc8929037c70515df83:
>
> Merge branch 'for-kvm' into next (2013-10-11 18:23:53 +1100)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
>
> for you to fetch changes up to b60c5a7a82cdfec2221263ce259faa4a36696163:
>
> powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module (2013-10-28 21:11:24 -0500)
Sigh, I just saw Kumar's e-mail about the build breakage with
CONFIG_PPC_EMULATED_STATS (I got dropped from the CC list at some
point). CONFIG_PPC_EMULATED_STATS should probably be enabled by
default, and by default print the first emulation of each type rather
than just using printk_ratelimited(). I'll send a fix for the build
breakage.
-Scott
^ permalink raw reply
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2013-10-29 2:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Sorry again for the lateness. I tried to get this done before the
conferences last week, but it just didn't happen.
Highlights include corenet board file consolidation, the ability to run
userspaces with lwsync on e500v1/v2, some cleanup patches that other KVM
patches will build on, support for stripped-down e6500 emulation targets,
and some fixes of minor longstanding issues.
Some of the more complicated and/or more recently posted patches didn't
make it this time around; this doesn't mean I've forgotten them (as long
as they're in patchwork in an action required state), just that I've run
out of time for 3.13.
The following changes since commit 3ad26e5c4459d3793ad65bc8929037c70515df83:
Merge branch 'for-kvm' into next (2013-10-11 18:23:53 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to b60c5a7a82cdfec2221263ce259faa4a36696163:
powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module (2013-10-28 21:11:24 -0500)
----------------------------------------------------------------
Bharat Bhushan (3):
powerpc: remove unnecessary line continuations
powerpc: move debug registers in a structure
powerpc: export debug registers save function for KVM
Christian Kujau (1):
powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module
Chunhe Lan (1):
powerpc/pci: Change the DECLARE_PCI_FIXUP_{HEADER => EARLY} macro of pci quirk
Haijun.Zhang (2):
powerpc/eSDCH: Specify voltage for T4240QDS
powerpc/dts: Correct sdhci quirk for bsc9131
Hongtao Jia (1):
powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
James Yang (2):
powerpc: Emulate sync instruction variants
powerpc/booke: clear DBCR0_BT in user_disable_single_step()
Kevin Hao (3):
powerpc/85xx: introduce corenet_generic machine
powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
powerpc/85xx: use one kernel option for all the CoreNet_Generic boards
LEROY Christophe (4):
powerpc/mpc8xx: Clearer Oops message for Software Emulation Exception
powerpc/8xx: Revert commit e0908085fc2391c85b85fb814ae1df377c8e0dcb
powerpc/8xx: Fixing issue with CONFIG_PIN_TLB
powerpc/8xx: Fixing memory init issue with CONFIG_PIN_TLB
Lijun Pan (2):
powerpc/e6500: Include Power ISA properties
powerpc/e500v2: Include Power ISA properties
Mihai Caraman (2):
powerpc/booke64: Use common defines for AltiVec interrupts numbers
powerpc/fsl-booke: Use common defines for SPE/FP interrupts numbers
Minghuan Lian (1):
powerpc/dts: fix sRIO error interrupt for b4860
Paul Bolle (1):
powerpc: remove dependency on MV64360
Prabhakar Kushwaha (1):
powerpc/dts/c293pcie: Add range field for IFC NAND
Scott Wood (1):
powerpc/b4qds: enable coreint
Shengzhou Liu (1):
powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
Suzuki Poulose (1):
powerpc: Set the NOTE type for SPE regset
Tiejun Chen (1):
powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info
Wei Yongjun (2):
powerpc/6xx: add missing iounmap() on error in hlwd_pic_init()
powerpc/mv643xx_eth: fix return check in mv64x60_eth_register_shared_pdev()
Wolfram Sang (1):
arch/powerpc/platforms/83xx: Remove obsolete cleanup for clientdata
York Sun (2):
powerpc/t4240emu: Add device tree file for t4240emu
powerpc/b4860emu: Add device tree file for b4860emu
Zhao Qiang (1):
powerpc/p1010rdb: add P1010RDB-PB platform support
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/dts/b4860emu.dts | 218 ++++++++++++++++++++
arch/powerpc/boot/dts/b4qds.dtsi | 51 +++--
arch/powerpc/boot/dts/c293pcie.dts | 1 +
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi | 3 +
arch/powerpc/boot/dts/t4240emu.dts | 268 +++++++++++++++++++++++++
arch/powerpc/boot/dts/t4240qds.dts | 73 ++++---
arch/powerpc/configs/corenet32_smp_defconfig | 7 +-
arch/powerpc/configs/corenet64_smp_defconfig | 5 +-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/configs/ppc64e_defconfig | 2 +-
arch/powerpc/configs/ppc6xx_defconfig | 2 +-
arch/powerpc/include/asm/ppc-opcode.h | 2 +
arch/powerpc/include/asm/processor.h | 34 ++--
arch/powerpc/include/asm/reg_booke.h | 8 +-
arch/powerpc/include/asm/switch_to.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/exceptions-64e.S | 5 +-
arch/powerpc/kernel/head_8xx.S | 3 +
arch/powerpc/kernel/head_fsl_booke.S | 10 +-
arch/powerpc/kernel/kgdb.c | 6 +-
arch/powerpc/kernel/process.c | 45 +++--
arch/powerpc/kernel/ptrace.c | 156 +++++++-------
arch/powerpc/kernel/ptrace32.c | 2 +-
arch/powerpc/kernel/signal_32.c | 6 +-
arch/powerpc/kernel/traps.c | 45 +++--
arch/powerpc/mm/init_32.c | 5 +
arch/powerpc/mm/pgtable.c | 19 +-
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 1 -
arch/powerpc/platforms/85xx/Kconfig | 101 +---------
arch/powerpc/platforms/85xx/Makefile | 8 +-
arch/powerpc/platforms/85xx/b4_qds.c | 102 ----------
arch/powerpc/platforms/85xx/corenet_ds.c | 96 ---------
arch/powerpc/platforms/85xx/corenet_ds.h | 19 --
arch/powerpc/platforms/85xx/corenet_generic.c | 182 +++++++++++++++++
arch/powerpc/platforms/85xx/p1010rdb.c | 2 +
arch/powerpc/platforms/85xx/p2041_rdb.c | 87 --------
arch/powerpc/platforms/85xx/p3041_ds.c | 89 --------
arch/powerpc/platforms/85xx/p4080_ds.c | 87 --------
arch/powerpc/platforms/85xx/p5020_ds.c | 93 ---------
arch/powerpc/platforms/85xx/p5040_ds.c | 84 --------
arch/powerpc/platforms/85xx/t4240_qds.c | 93 ---------
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 +
arch/powerpc/sysdev/fsl_pci.c | 5 +-
arch/powerpc/sysdev/mv64x60_dev.c | 2 +-
50 files changed, 962 insertions(+), 1081 deletions(-)
create mode 100644 arch/powerpc/boot/dts/b4860emu.dts
create mode 100644 arch/powerpc/boot/dts/t4240emu.dts
delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
create mode 100644 arch/powerpc/platforms/85xx/corenet_generic.c
delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
^ permalink raw reply
* Re: [PATCH 1/2][v8] powerpc/mpc85xx:Add initial device tree support of T104x
From: Scott Wood @ 2013-10-29 1:11 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Varun Sethi, linuxppc-dev, Poonam Aggrwal, Priyanka Jain
In-Reply-To: <5264A161.6030803@freescale.com>
On Mon, 2013-10-21 at 09:07 +0530, Prabhakar Kushwaha wrote:
> Hi Ben,
>
> This patch is present in upstream review list from a long time.
> There are no review comments.
>
> So, I request you to pick this patch-set for powerpc.git repository.
> http://patchwork.ozlabs.org/patch/280207/
> http://patchwork.ozlabs.org/patch/280208/
This revision has only been posted for about 2.5 weeks.
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + pll0: pll0@800 {
> > + #clock-cells = <1>;
> > + reg = <0x800 4>;
> > + compatible = "fsl,qoriq-core-pll-2.0";
> > + clocks = <&clockgen>;
> > + clock-output-names = "pll0", "pll0-div2", "pll0-div4";
> > + };
> > + pll1: pll1@820 {
> > + #clock-cells = <1>;
> > + reg = <0x820 4>;
> > + compatible = "fsl,qoriq-core-pll-2.0";
> > + clocks = <&clockgen>;
> > + clock-output-names = "pll1", "pll1-div2", "pll1-div4";
> > + };
> > + mux0: mux0@0 {
> > + #clock-cells = <0>;
> > + reg = <0x0 4>;
> > + compatible = "fsl,core-mux-clock";
> > + clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
> > + <&pll1 0>, <&pll1 1>, <&pll1 2>;
> > + clock-names = "pll0_0", "pll0_1", "pll0_2",
> > + "pll1_0", "pll1_1", "pll1_2";
> > + clock-output-names = "cmux0";
> > + };
The clock bindings are still under discussion.
> > +++ b/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
> > @@ -0,0 +1,106 @@
> > +/*
> > + * T1040/T1042 Silicon/SoC Device Tree Source (pre include)
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote products
> > + * derived from this software without specific prior written permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of the
> > + * GNU General Public License ("GPL") as published by the Free Software
> > + * Foundation, either version 2 of that License or (at your option) any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/include/ "e5500_power_isa.dtsi"
> > +
> > +/ {
> > + compatible = "fsl,T104x";
No wildcards in compatibles. If your response is that this will get
overwritten anyway, then why have compatible here at all?
> > + crypto = &crypto;
> > +
> > + };
No blank lines before a closing brace.
-Scott
^ permalink raw reply
* Re: [5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
From: York Sun @ 2013-10-29 0:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20131029002834.GA8680@home.buserror.net>
On 10/28/2013 05:28 PM, Scott Wood wrote:
> On Fri, Sep 06, 2013 at 08:43:17AM -0700, York Sun wrote:
>> Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on
>> P5040DS.
>>
>> Signed-off-by: York Sun <yorksun@freescale.com>
>> Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
>> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
>> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
>>
>> ---
>> arch/powerpc/configs/corenet64_smp_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
>> index 6c8b020..1ec6f0c 100644
>> --- a/arch/powerpc/configs/corenet64_smp_defconfig
>> +++ b/arch/powerpc/configs/corenet64_smp_defconfig
>> @@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
>> CONFIG_MTD_CHAR=y
>> CONFIG_MTD_BLKDEVS=y
>> CONFIG_MTD_BLOCK=y
>> +CONFIG_MTD_M25P80=y
>> CONFIG_FTL=y
>> CONFIG_MTD_CFI=y
>> CONFIG_MTD_GEN_PROBE=y
>
> This has already been enabled in corenet64_smp_config since
> commit 478a4829d815865b919c1fa20f0f33543a2291fb, over a year ago.
>
Oh. Thanks. Please drop it then.
York
^ permalink raw reply
* Re: [5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
From: Scott Wood @ 2013-10-29 0:28 UTC (permalink / raw)
To: York Sun; +Cc: linuxppc-dev
In-Reply-To: <1378482199-10581-5-git-send-email-yorksun@freescale.com>
On Fri, Sep 06, 2013 at 08:43:17AM -0700, York Sun wrote:
> Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on
> P5040DS.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Reviewed-by: Wood Scott-B07421 <scottwood@freescale.com>
> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
>
> ---
> arch/powerpc/configs/corenet64_smp_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
> index 6c8b020..1ec6f0c 100644
> --- a/arch/powerpc/configs/corenet64_smp_defconfig
> +++ b/arch/powerpc/configs/corenet64_smp_defconfig
> @@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CHAR=y
> CONFIG_MTD_BLKDEVS=y
> CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_M25P80=y
> CONFIG_FTL=y
> CONFIG_MTD_CFI=y
> CONFIG_MTD_GEN_PROBE=y
This has already been enabled in corenet64_smp_config since
commit 478a4829d815865b919c1fa20f0f33543a2291fb, over a year ago.
-Scott
^ permalink raw reply
* Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
From: Jason Gunthorpe @ 2013-10-28 23:47 UTC (permalink / raw)
To: Joel Schopp; +Cc: Peter H?we, tpmdd-devel, linuxppc-dev
In-Reply-To: <526EA6FF.2080401@linux.vnet.ibm.com>
On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote:
> On 10/27/2013 05:06 PM, Peter H?we wrote:
> > Hi,
> >
> > I was wondering if anyone here on this list still has a machine with an old
> > ATMEL TPM (trusted platform module) lying around?
> >
> >>From the kconfig entry it becomes evident that it was only supported on ppc64
> > machines.
> >
> > config TCG_ATMEL
> > tristate "Atmel TPM Interface"
> > depends on PPC64 || HAS_IOPORT
Hurm, that is crazy, because tpm_atmel.h contains an #else block for
!CONFIG_PPC64. The single major source of complexity in this driver is
that else block.
The driver would be fine, and straightforward if it was a standard,
modern DT enabled driver, which is very easy if PPC64 is the only
supported implementation.
> I reccomend removing the driver. If the stars align and a user actually
> appears who wants to use one I'll clean up the driver and resubmit it
> for inclusion. I just don't think that will happen.
The needed clean up is really easy actually, replace everything below
'tpm_vendor_specific tpm_atmel' with approximately this:
static int atml_probe(struct platform_device *pdev)
{
struct tpm_chip *chip;
struct resrouce *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r)
return -EIO;
if (!(chip = tpm_register_hardware(dev, &tpm_atmel)))
return -ENODEV;
chip->iobase = devm_request_and_ioremap(&pdev->dev, res);
if (!chip->iobase)
return -ENOMEM;
return 0;
}
static void atml_plat_remove(struct platform_device *pdev)
{
struct tpm_chip *chip = dev_get_drvdata(&pdev->dev);
tpm_remove_hardware(chip->dev);
};
static const struct of_device_id platform_match[] = {
{.compatible = "AT97SC3201"},
{},
};
MODULE_DEVICE_TABLE(of, platform_match);
static SIMPLE_DEV_PM_OPS(tpm_atml_pm, tpm_pm_suspend, tpm_pm_resume);
static struct platform_driver atml_drv = {
.probe = atml_probe,
.remove = atml_plat_remove,
.driver = {
.name = "tpm_atmel",
.owner = THIS_MODULE,
.pm = &tpm_atml_pm,
.of_match_table = of_match_ptr(platform_match),
},
};
module_platform_driver(atml_drv);
MODULE_AUTHOR("Leendert van Doorn (leendert@watson.ibm.com)");
MODULE_DESCRIPTION("TPM Driver");
MODULE_VERSION("2.0");
MODULE_LICENSE("GPL");
If you guys can convice yourselves that doesn't obviously break anything I can
probably send a proper patch.
Jason
^ permalink raw reply
* Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
From: Peter Hüwe @ 2013-10-29 0:03 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Joel Schopp, tpmdd-devel, linuxppc-dev
In-Reply-To: <20131028234745.GB26666@obsidianresearch.com>
Am Dienstag, 29. Oktober 2013, 00:47:45 schrieb Jason Gunthorpe:
> On Mon, Oct 28, 2013 at 01:03:43PM -0500, Joel Schopp wrote:
> > On 10/27/2013 05:06 PM, Peter H?we wrote:
> > > Hi,
> > >
> > > I was wondering if anyone here on this list still has a machine with an
> > > old ATMEL TPM (trusted platform module) lying around?
> > >
> > >>From the kconfig entry it becomes evident that it was only supported on
> > >>ppc64
> > >>
> > > machines.
> > >
> > > config TCG_ATMEL
> > >
> > > tristate "Atmel TPM Interface"
> > > depends on PPC64 || HAS_IOPORT
>
> Hurm, that is crazy, because tpm_atmel.h contains an #else block for
> !CONFIG_PPC64. The single major source of complexity in this driver is
> that else block.
>
Argh, sorry my bad.
Of course it's available on other archs as well, since it's
PPC64 _||_ HAS_IOPORT
d'oh - sorry.
Peter
^ permalink raw reply
* Re: linux-next: build failure after merge of the dt-rh tree
From: Rob Herring @ 2013-10-28 23:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-kernel, Rob Herring, linux-next, linuxppc-dev
In-Reply-To: <20131028193814.6d9416904eb8fac2f441c8af@canb.auug.org.au>
On 10/28/2013 03:38 AM, Stephen Rothwell wrote:
> Hi Rob,
>
> After merging the dt-rh tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/powernv/rng.c: In function
> 'rng_init_per_cpu': arch/powerpc/platforms/powernv/rng.c:64:2:
> error: implicit declaration of function 'of_get_ibm_chip_id'
> [-Werror=implicit-function-declaration] chip_id =
> of_get_ibm_chip_id(dn); ^ arch/powerpc/platforms/powernv/rng.c: In
> function 'rng_create': arch/powerpc/platforms/powernv/rng.c:85:2:
> error: implicit declaration of function 'of_iomap'
> [-Werror=implicit-function-declaration] rng->regs= of_iomap(dn, 0);
> ^
> arch/powerpc/platforms/powernv/rng.c:85:12: error: assignment makes pointer from integer without a cast [-Werror]
> rng->regs = of_iomap(dn, 0);
> ^
>
> Caused by commit a4da0d50b2a0 ("powerpc: Implement
> arch_get_random_long/int() for powernv") from the powerpc tree
> interacting with commit b5b4bb3f6a11 ("of: only include prom.h on sparc")
> from the dt-rh tree.
>
> I added this merge fix patch (which will need to be sent to Linus when
> these two trees get merged, or could be applied now to the powerpc tree):
Applying to the powerpc tree now seems like the better path.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 28 Oct 2013 19:34:41 +1100
> Subject: [PATCH] powerpc: add include of prom.h to fix powernv/rng.c build
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-10-28 20:58 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Paul E. McKenney
In-Reply-To: <20131028201735.GA15629@redhat.com>
Oleg Nesterov <oleg@redhat.com> wrote on 10/28/2013 10:17:35 PM:
> mb(); // XXXXXXXX: do we really need it? I think yes.
Oh, it is hard to argue with feelings. Also, it is easy to be on
conservative side and put the barrier here just in case.
But I still insist that the barrier is redundant in your example.
-- Victor
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Oleg Nesterov @ 2013-10-28 20:17 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131028163418.GD4126@linux.vnet.ibm.com>
On 10/28, Paul E. McKenney wrote:
>
> On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
> > --- linux-2.6.orig/kernel/events/ring_buffer.c
> > +++ linux-2.6/kernel/events/ring_buffer.c
> > @@ -87,10 +87,31 @@ static void perf_output_put_handle(struc
> > goto out;
> >
> > /*
> > - * Publish the known good head. Rely on the full barrier implied
> > - * by atomic_dec_and_test() order the rb->head read and this
> > - * write.
> > + * Since the mmap() consumer (userspace) can run on a different CPU:
> > + *
> > + * kernel user
> > + *
> > + * READ ->data_tail READ ->data_head
> > + * smp_rmb() (A) smp_rmb() (C)
>
> Given that both of the kernel's subsequent operations are stores/writes,
> doesn't (A) need to be smp_mb()?
Yes, this is my understanding^Wfeeling too, but I have to admit that
I can't really explain to myself why _exactly_ we need mb() here.
And let me copy-and-paste the artificial example from my previous
email,
bool BUSY;
data_t DATA;
bool try_to_get(data_t *data)
{
if (!BUSY)
return false;
rmb();
*data = DATA;
mb();
BUSY = false;
return true;
}
bool try_to_put(data_t *data)
{
if (BUSY)
return false;
mb(); // XXXXXXXX: do we really need it? I think yes.
DATA = *data;
wmb();
BUSY = true;
return true;
}
(just in case, the code above obviously assumes that _get or _put
can't race with itself, but they can race with each other).
Could you confirm that try_to_put() actually needs mb() between
LOAD(BUSY) and STORE(DATA) ?
I am sure it actually needs, but I will appreciate it if you can
explain why. IOW, how it is possible that without mb() try_to_put()
can overwrite DATA before try_to_get() completes its "*data = DATA"
in this particular case.
Perhaps this can happen if, say, reader and writer share a level of
cache or something like this...
Oleg.
^ permalink raw reply
* Re: Build regressions/improvements in v3.12-rc7
From: Geert Uytterhoeven @ 2013-10-28 19:31 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Linux/PPC Development, linux-sh
In-Reply-To: <alpine.DEB.2.02.1310282028510.14364@ayla.of.borg>
On Mon, 28 Oct 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.12-rc7 to v3.12-rc6[3], the summaries are:
> - build errors: +9/-10
+ /scratch/kisskb/src/arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used uninitialized in this function [-Werror=uninitialized]: => 575:2
+ /scratch/kisskb/src/arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may be used uninitialized in this function [-Werror=uninitialized]: => 526:2
+ /scratch/kisskb/src/drivers/tty/serial/nwpserial.c: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration]: => 53:3
powerpc-randconfig
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error: implicit declaration of function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration]: => 91:2
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error: implicit declaration of function 'dma_free_writecombine' [-Werror=implicit-function-declaration]: => 176:3
sh-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6819/ (119 out of 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6796/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 02/12][v3] pci: fsl: add structure fsl_pci
From: Scott Wood @ 2013-10-28 18:22 UTC (permalink / raw)
To: Lian Minghuan-b31939
Cc: Arnd Bergmann, linux-pci, Minghuan Lian, Bjorn Helgaas,
linuxppc-dev@lists.ozlabs.org list, linux-arm-kernel
In-Reply-To: <526A086E.305@freescale.com>
On Fri, 2013-10-25 at 13:58 +0800, Lian Minghuan-b31939 wrote:
> Hi Kumar,
>
> please see my comment inline.
>
> On 10/24/2013 12:11 PM, Kumar Gala wrote:
> > On Oct 23, 2013, at 5:41 AM, Minghuan Lian wrote:
> >
> >> PowerPC uses structure pci_controller to describe PCI controller,
> >> but ARM uses structure pci_sys_data. In order to support PowerPC
> >> and ARM simultaneously, the patch adds a structure fsl_pci that
> >> contains most of the members of the pci_controller and pci_sys_data.
> >> Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should
> >> be implemented in architecture-specific PCI controller driver to
> >> convert pci_controller or pci_sys_data to fsl_pci.
> >>
> >> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> >> ---
> >> change log:
> >> v1-v3:
> >> Derived from http://patchwork.ozlabs.org/patch/278965/
> >>
> >> Based on upstream master.
> >> Based on the discussion of RFC version here
> >> http://patchwork.ozlabs.org/patch/274487/
> >>
> >> include/linux/fsl/pci-common.h | 41 +++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 41 insertions(+)
> > NAK.
> >
> > We discussed this some at the ARM Summit this week and the feeling is we need to move to a common interface between the various ARCHs.
> [Minghuan] Do you mean we will use the common interface instead of
> arch/powerpc/kernel/pci-common.c...
> and arch/arm/kernel/bios32.c? Who will do the code movement and when
> will the work be completed? The patches just move the common functions
> of FSL PCI controller operation which can be re-used by PowerPC and ARM.
> LS1 is coming, I worry about not having enough time to wait for the move
> is completed.
I agree -- it can take quite a while to get from "the feeling is we need
to move to a common interface" to actually having something we can use.
If and when this unification is achieved, we can drop this extra layer.
It's a better interim solution than just duplicating the entire driver
and letting them drift apart.
-Scott
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Oleg Nesterov @ 2013-10-28 19:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, Frederic Weisbecker, LKML,
Linux PPC dev, Anton Blanchard, Victor Kaplansky, Paul McKenney
In-Reply-To: <20131028132634.GO19466@laptop.lan>
On 10/28, Peter Zijlstra wrote:
>
> Lets add Paul and Oleg to the thread; this is getting far more 'fun'
> that it should be ;-)
Heh. All I can say is that I would like to see the authoritative answer,
you know who can shed a light ;)
But to avoid the confusion, wmb() added by this patch looks "obviously
correct" to me.
> + * Since the mmap() consumer (userspace) can run on a different CPU:
> + *
> + * kernel user
> + *
> + * READ ->data_tail READ ->data_head
> + * smp_rmb() (A) smp_rmb() (C)
> + * WRITE $data READ $data
> + * smp_wmb() (B) smp_mb() (D)
> + * STORE ->data_head WRITE ->data_tail
> + *
> + * Where A pairs with D, and B pairs with C.
> + *
> + * I don't think A needs to be a full barrier because we won't in fact
> + * write data until we see the store from userspace.
this matches the intuition, but ...
> So we simply don't
> + * issue the data WRITE until we observe it.
why do we need any barrier (rmb) then? how it can help to serialize with
"WRITE $data" ?
(of course there could be other reasons for this rmb(), just I can't
really understand "A pairs with D").
And this reminds me about the memory barrier in kfifo.c which I was not
able to understand. Hmm, it has already gone away, and now I do not
understand kfifo.c at all ;) But I have found the commit, attached below.
Note that that commit added the full barrier into __kfifo_put(). And to
me it looks the same as "A" above. Following the logic above we could say
that we do not need a barrier (at least the full one), we won't in fact
write into the "unread" area until we see the store to ->out from
__kfifo_get() ?
In short. I am confused, I _feel_ that "A" has to be a full barrier, but
I can't prove this. And let me suggest the artificial/simplified example,
bool BUSY;
data_t DATA;
bool try_to_get(data_t *data)
{
if (!BUSY)
return false;
rmb();
*data = DATA;
mb();
BUSY = false;
return true;
}
bool try_to_put(data_t *data)
{
if (BUSY)
return false;
mb(); // XXXXXXXX: do we really need it? I think yes.
DATA = *data;
wmb();
BUSY = true;
return true;
}
Again, following the description above we could turn the mb() in _put()
into barrier(), but I do not think we can rely on the contorl dependency.
Oleg.
---
commit a45bce49545739a940f8bd4ca85c3b7435564893
Author: Paul E. McKenney <paulmck@us.ibm.com>
Date: Fri Sep 29 02:00:11 2006 -0700
[PATCH] memory ordering in __kfifo primitives
Both __kfifo_put() and __kfifo_get() have header comments stating that if
there is but one concurrent reader and one concurrent writer, locking is not
necessary. This is almost the case, but a couple of memory barriers are
needed. Another option would be to change the header comments to remove the
bit about locking not being needed, and to change the those callers who
currently don't use locking to add the required locking. The attachment
analyzes this approach, but the patch below seems simpler.
Signed-off-by: Paul E. McKenney <paulmck@us.ibm.com>
Cc: Stelian Pop <stelian@popies.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index 64ab045..5d1d907 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -122,6 +122,13 @@ unsigned int __kfifo_put(struct kfifo *fifo,
len = min(len, fifo->size - fifo->in + fifo->out);
+ /*
+ * Ensure that we sample the fifo->out index -before- we
+ * start putting bytes into the kfifo.
+ */
+
+ smp_mb();
+
/* first put the data starting from fifo->in to buffer end */
l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));
memcpy(fifo->buffer + (fifo->in & (fifo->size - 1)), buffer, l);
@@ -129,6 +136,13 @@ unsigned int __kfifo_put(struct kfifo *fifo,
/* then put the rest (if any) at the beginning of the buffer */
memcpy(fifo->buffer, buffer + l, len - l);
+ /*
+ * Ensure that we add the bytes to the kfifo -before-
+ * we update the fifo->in index.
+ */
+
+ smp_wmb();
+
fifo->in += len;
return len;
@@ -154,6 +168,13 @@ unsigned int __kfifo_get(struct kfifo *fifo,
len = min(len, fifo->in - fifo->out);
+ /*
+ * Ensure that we sample the fifo->in index -before- we
+ * start removing bytes from the kfifo.
+ */
+
+ smp_rmb();
+
/* first get the data from fifo->out until the end of the buffer */
l = min(len, fifo->size - (fifo->out & (fifo->size - 1)));
memcpy(buffer, fifo->buffer + (fifo->out & (fifo->size - 1)), l);
@@ -161,6 +182,13 @@ unsigned int __kfifo_get(struct kfifo *fifo,
/* then get the rest (if any) from the beginning of the buffer */
memcpy(buffer + l, fifo->buffer, len - l);
+ /*
+ * Ensure that we remove the bytes from the kfifo -before-
+ * we update the fifo->out index.
+ */
+
+ smp_mb();
+
fifo->out += len;
return len;
^ permalink raw reply related
* Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
From: Joel Schopp @ 2013-10-28 18:03 UTC (permalink / raw)
To: Peter Hüwe, linuxppc-dev, tpmdd-devel
In-Reply-To: <201310272306.09310.PeterHuewe@gmx.de>
On 10/27/2013 05:06 PM, Peter Hüwe wrote:
> Hi,
>
> I was wondering if anyone here on this list still has a machine with an old
> ATMEL TPM (trusted platform module) lying around?
>
>>From the kconfig entry it becomes evident that it was only supported on ppc64
> machines.
>
> config TCG_ATMEL
> tristate "Atmel TPM Interface"
> depends on PPC64 || HAS_IOPORT
> ---help---
> If you have a TPM security chip from Atmel say Yes and it
> will be accessible from within Linux. To compile this driver
> as a module, choose M here; the module will be called tpm_atmel.
>
> The hardware/driver is pretty old and the driver might have contained a bug
> that made it unusable for the last 6 years ;)
>
> So if anyone still has this kind of hardware around, please reply.
>
As near as I can tell this was on a single machine type (the js21 circa
2006). The firmware on the machine didn't support establishing a root
of trust, so use of the TPM was as a practical matter effective only for
the other functions like random number generation and key management.
The number of users who used the TPM for this on this machine was likely
very small 7 years ago. The number of those machines still in service
today is likely smaller still. The cross section of those two small
numbers combined with those who want to run on a shiny new kernel has to
be quickly approaching zero.
I reccomend removing the driver. If the stars align and a user actually
appears who wants to use one I'll clean up the driver and resubmit it
for inclusion. I just don't think that will happen.
-Joel
^ permalink raw reply
* Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
From: Scott Wood @ 2013-10-28 17:52 UTC (permalink / raw)
To: James Yang; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <alpine.LRH.2.00.1310251020590.31001@ra8135-ec1.am.freescale.net>
On Fri, 2013-10-25 at 10:25 -0500, James Yang wrote:
> On Fri, 25 Oct 2013, Scott Wood wrote:
>
> > Has anyone measured how much this slows things down with a typical
> > userspace?
>
> Not a measurement of the patch in question but an older similar patch
> on 3.0.51 (8572 running Debian 5.0.3):
>
> $ ./test-lwsync
> cycles per emulated lwsync = 371
> cycles per sync = 36
My point was more to find out how often a typical userspace executes
these instructions. From Wolfgang's e-mail it seems the answer is not
very often.
-Scott
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-10-28 16:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, Frederic Weisbecker, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard, Victor Kaplansky
In-Reply-To: <20131028132634.GO19466@laptop.lan>
On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 28, 2013 at 02:38:29PM +0200, Victor Kaplansky wrote:
> > > 2013/10/25 Peter Zijlstra <peterz@infradead.org>:
> > > > On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
> > > > I would argue for
> > > >
> > > > READ ->data_tail READ ->data_head
> > > > smp_rmb() (A) smp_rmb() (C)
> > > > WRITE $data READ $data
> > > > smp_wmb() (B) smp_mb() (D)
> > > > STORE ->data_head WRITE ->data_tail
> > > >
> > > > Where A pairs with D, and B pairs with C.
> > > >
> > > > I don't think A needs to be a full barrier because we won't in fact
> > > > write data until we see the store from userspace. So we simply don't
> > > > issue the data WRITE until we observe it.
> > > >
> > > > OTOH, D needs to be a full barrier since it separates the data READ from
> > > > the tail WRITE.
> > > >
> > > > For B a WMB is sufficient since it separates two WRITEs, and for C an
> > > > RMB is sufficient since it separates two READs.
>
> <snip>
>
> > I think you have a point :) IMO, memory barrier (A) is superfluous.
> > At producer side we need to ensure that "WRITE $data" is not committed
> > to memory before "READ ->data_tail" had seen a new value and if the
> > old one indicated that there is no enough space for a new entry. All
> > this is already guaranteed by control flow dependancy on single CPU -
> > writes will not be committed to the memory if read value of
> > "data_tail" doesn't specify enough free space in the ring buffer.
> >
> > Likewise, on consumer side, we can make use of natural data dependency and
> > memory ordering guarantee for single CPU and try to replace "smp_mb" by
> > a more light-weight "smp_rmb":
> >
> > READ ->data_tail READ ->data_head
> > // ... smp_rmb() (C)
> > WRITE $data READ $data
> > smp_wmb() (B) smp_rmb() (D)
> > READ $header_size
> > STORE ->data_head WRITE ->data_tail = $old_data_tail +
> > $header_size
> >
> > We ensure that all $data is read before "data_tail" is written by
> > doing "READ $header_size" after all other data is read and we rely on
> > natural data dependancy between "data_tail" write and "header_size"
> > read.
>
> I'm not entirely sure I get the $header_size trickery; need to think
> more on that. But yes, I did consider the other one. However, I had
> trouble having no pairing barrier for (D).
>
> ISTR something like Alpha being able to miss the update (for a long
> while) if you don't issue the RMB.
>
> Lets add Paul and Oleg to the thread; this is getting far more 'fun'
> that it should be ;-)
>
> For completeness; below the patch as I had queued it.
> ---
> Subject: perf: Fix perf ring buffer memory ordering
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Mon Oct 28 13:55:29 CET 2013
>
> The PPC64 people noticed a missing memory barrier and crufty old
> comments in the perf ring buffer code. So update all the comments and
> add the missing barrier.
>
> When the architecture implements local_t using atomic_long_t there
> will be double barriers issued; but short of introducing more
> conditional barrier primitives this is the best we can do.
>
> Cc: anton@samba.org
> Cc: benh@kernel.crashing.org
> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Cc: michael@ellerman.id.au
> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Michael Neuling <mikey@neuling.org>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Reported-by: Victor Kaplansky <victork@il.ibm.com>
> Tested-by: Victor Kaplansky <victork@il.ibm.com>
> Signed-off-by: Peter Zijlstra <peterz@infradead.org>
> Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan
> ---
> include/uapi/linux/perf_event.h | 12 +++++++-----
> kernel/events/ring_buffer.c | 29 ++++++++++++++++++++++++++---
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
> Index: linux-2.6/include/uapi/linux/perf_event.h
> ===================================================================
> --- linux-2.6.orig/include/uapi/linux/perf_event.h
> +++ linux-2.6/include/uapi/linux/perf_event.h
> @@ -479,13 +479,15 @@ struct perf_event_mmap_page {
> /*
> * Control data for the mmap() data buffer.
> *
> - * User-space reading the @data_head value should issue an rmb(), on
> - * SMP capable platforms, after reading this value -- see
> - * perf_event_wakeup().
> + * User-space reading the @data_head value should issue an smp_rmb(),
> + * after reading this value.
> *
> * When the mapping is PROT_WRITE the @data_tail value should be
> - * written by userspace to reflect the last read data. In this case
> - * the kernel will not over-write unread data.
> + * written by userspace to reflect the last read data, after issueing
> + * an smp_mb() to separate the data read from the ->data_tail store.
> + * In this case the kernel will not over-write unread data.
> + *
> + * See perf_output_put_handle() for the data ordering.
> */
> __u64 data_head; /* head in the data section */
> __u64 data_tail; /* user-space written tail */
> Index: linux-2.6/kernel/events/ring_buffer.c
> ===================================================================
> --- linux-2.6.orig/kernel/events/ring_buffer.c
> +++ linux-2.6/kernel/events/ring_buffer.c
> @@ -87,10 +87,31 @@ static void perf_output_put_handle(struc
> goto out;
>
> /*
> - * Publish the known good head. Rely on the full barrier implied
> - * by atomic_dec_and_test() order the rb->head read and this
> - * write.
> + * Since the mmap() consumer (userspace) can run on a different CPU:
> + *
> + * kernel user
> + *
> + * READ ->data_tail READ ->data_head
> + * smp_rmb() (A) smp_rmb() (C)
Given that both of the kernel's subsequent operations are stores/writes,
doesn't (A) need to be smp_mb()?
Thanx, Paul
> + * WRITE $data READ $data
> + * smp_wmb() (B) smp_mb() (D)
> + * STORE ->data_head WRITE ->data_tail
> + *
> + * Where A pairs with D, and B pairs with C.
> + *
> + * I don't think A needs to be a full barrier because we won't in fact
> + * write data until we see the store from userspace. So we simply don't
> + * issue the data WRITE until we observe it.
> + *
> + * OTOH, D needs to be a full barrier since it separates the data READ
> + * from the tail WRITE.
> + *
> + * For B a WMB is sufficient since it separates two WRITEs, and for C
> + * an RMB is sufficient since it separates two READs.
> + *
> + * See perf_output_begin().
> */
> + smp_wmb();
> rb->user_page->data_head = head;
>
> /*
> @@ -154,6 +175,8 @@ int perf_output_begin(struct perf_output
> * Userspace could choose to issue a mb() before updating the
> * tail pointer. So that all reads will be completed before the
> * write is issued.
> + *
> + * See perf_output_put_handle().
> */
> tail = ACCESS_ONCE(rb->user_page->data_tail);
> smp_rmb();
>
^ permalink raw reply
* Re: [PATCH 3/3] sched: Aggressive balance in domains whose groups share package resources
From: Peter Zijlstra @ 2013-10-28 15:53 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: Michael Neuling, Mike Galbraith, linuxppc-dev, linux-kernel,
Anton Blanchard, Preeti U Murthy, Paul Turner, Ingo Molnar
In-Reply-To: <20131021114502.13291.60794.stgit@drishya>
On Mon, Oct 21, 2013 at 05:15:02PM +0530, Vaidyanathan Srinivasan wrote:
> From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
>
> The current logic in load balance is such that after picking the
> busiest group, the load is attempted to be moved from the busiest cpu
> in that group to the dst_cpu. If the load cannot be moved from the
> busiest cpu to dst_cpu due to either tsk_cpus_allowed mask or cache
> hot tasks, then the dst_cpu is changed to be another idle cpu within
> the dst->grpmask. If even then, the load cannot be moved from the
> busiest cpu, then the source group is changed. The next busiest group
> is found and the above steps are repeated.
>
> However if the cpus in the group share package resources, then when
> a load movement from the busiest cpu in this group fails as above,
> instead of finding the next busiest group to move load from, find the
> next busiest cpu *within the same group* from which to move load away.
> By doing so, a conscious effort is made during load balancing to keep
> just one cpu busy as much as possible within domains that have
> SHARED_PKG_RESOURCES flag set unless under scenarios of high load.
> Having multiple cpus busy within a domain which share package resource
> could lead to a performance hit.
>
> A similar scenario arises in active load balancing as well. When the
> current task on the busiest cpu cannot be moved away due to task
> pinning, currently no more attempts at load balancing is made.
> This
> patch checks if the balancing is being done on a group whose cpus
> share package resources. If so, then check if the load balancing can
> be done for other cpus in the same group.
So I absolutely hate this patch... Also I'm not convinced I actually
understand the explanation above.
Furthermore; there is nothing special about spreading tasks for
SHARED_PKG_RESOURCES and special casing that one case is just wrong.
If anything it should be keyed off of SD_PREFER_SIBLING and or
cpu_power.
^ permalink raw reply
* [PATCH v2 0/2] powerpc: Sparse fixes for numa.c
From: Robert C Jennings @ 2013-10-28 14:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Robert C Jennings
Cleaning out some stashed fixes for sparse warnings found while
working on 3be7db6: (powerpc: VPHN topology change updates all siblings)
I don't see a reason why the declarations in arch/powerpc/kernel/setup.h
can't live in arch/powerpc/include/asm/setup.h and .../mm/numa.c
should include these definitions.
Robert C Jennings (2):
powerpc: Fix warnings for arch/powerpc/mm/numa.c
powerpc: Move local setup.h declarations to arch includes
arch/powerpc/include/asm/setup.h | 4 ++++
arch/powerpc/kernel/module.c | 3 +--
arch/powerpc/kernel/module_32.c | 3 +--
arch/powerpc/kernel/module_64.c | 3 +--
arch/powerpc/kernel/setup-common.c | 2 --
arch/powerpc/kernel/setup.h | 9 ---------
arch/powerpc/kernel/setup_32.c | 2 --
arch/powerpc/kernel/setup_64.c | 2 --
arch/powerpc/kernel/vdso.c | 3 +--
arch/powerpc/mm/numa.c | 8 ++++----
10 files changed, 12 insertions(+), 27 deletions(-)
delete mode 100644 arch/powerpc/kernel/setup.h
--
1.8.1.2
^ permalink raw reply
* [PATCH v2 2/2] powerpc: Move local setup.h declarations to arch includes
From: Robert C Jennings @ 2013-10-28 14:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Robert C Jennings
In-Reply-To: <1382970051-8251-1-git-send-email-rcj@linux.vnet.ibm.com>
Move the few declarations from arch/powerpc/kernel/setup.h
into arch/powerpc/include/asm/setup.h. This resolves a
sparse warning for arch/powerpc/mm/numa.c which defines
do_init_bootmem() but can't include the setup.h header
in the prior path.
Resolves:
arch/powerpc/mm/numa.c:998:13:
warning: symbol 'do_init_bootmem' was not declared.
Should it be static?
Signed-off-by: Robert C Jennings <rcj@linux.vnet.ibm.com>
---
v1 -> v2:
Removed do_early_xmon (unused since 47679283)
Removed 'extern' keyword
---
arch/powerpc/include/asm/setup.h | 4 ++++
arch/powerpc/kernel/module.c | 3 +--
arch/powerpc/kernel/module_32.c | 3 +--
arch/powerpc/kernel/module_64.c | 3 +--
arch/powerpc/kernel/setup-common.c | 2 --
arch/powerpc/kernel/setup.h | 9 ---------
arch/powerpc/kernel/setup_32.c | 2 --
arch/powerpc/kernel/setup_64.c | 2 --
arch/powerpc/kernel/vdso.c | 3 +--
9 files changed, 8 insertions(+), 23 deletions(-)
delete mode 100644 arch/powerpc/kernel/setup.h
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index d3ca855..703a841 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -23,6 +23,10 @@ extern void reloc_got2(unsigned long);
#define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x)))
+void check_for_initrd(void);
+void do_init_bootmem(void);
+void setup_panic(void);
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_SETUP_H */
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 2d27570..9547381 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -25,8 +25,7 @@
#include <asm/uaccess.h>
#include <asm/firmware.h>
#include <linux/sort.h>
-
-#include "setup.h"
+#include <asm/setup.h>
LIST_HEAD(module_bug_list);
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 2e3200c..6cff040 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -26,8 +26,7 @@
#include <linux/cache.h>
#include <linux/bug.h>
#include <linux/sort.h>
-
-#include "setup.h"
+#include <asm/setup.h>
#if 0
#define DEBUGP printk
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index a102f44..12664c1 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -26,8 +26,7 @@
#include <asm/firmware.h>
#include <asm/code-patching.h>
#include <linux/sort.h>
-
-#include "setup.h"
+#include <asm/setup.h>
/* FIXME: We don't do .init separately. To do this, we'd need to have
a separate r2 value in the init and core section, and stub between
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 3d261c0..febc804 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -62,8 +62,6 @@
#include <mm/mmu_decl.h>
#include <asm/fadump.h>
-#include "setup.h"
-
#ifdef DEBUG
#include <asm/udbg.h>
#define DBG(fmt...) udbg_printf(fmt)
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
deleted file mode 100644
index 4c67ad7..0000000
--- a/arch/powerpc/kernel/setup.h
+++ /dev/null
@@ -1,9 +0,0 @@
-#ifndef _POWERPC_KERNEL_SETUP_H
-#define _POWERPC_KERNEL_SETUP_H
-
-void check_for_initrd(void);
-void do_init_bootmem(void);
-void setup_panic(void);
-extern int do_early_xmon;
-
-#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index a4bbcae..b903dc5 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -40,8 +40,6 @@
#include <asm/mmu_context.h>
#include <asm/epapr_hcalls.h>
-#include "setup.h"
-
#define DBG(fmt...)
extern void bootx_init(unsigned long r4, unsigned long phys);
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 278ca93..4085aaa 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -68,8 +68,6 @@
#include <asm/hugetlb.h>
#include <asm/epapr_hcalls.h>
-#include "setup.h"
-
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 1d9c926..094e45c 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -34,8 +34,7 @@
#include <asm/firmware.h>
#include <asm/vdso.h>
#include <asm/vdso_datapage.h>
-
-#include "setup.h"
+#include <asm/setup.h>
#undef DEBUG
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2 1/2] powerpc: Fix warnings for arch/powerpc/mm/numa.c
From: Robert C Jennings @ 2013-10-28 14:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Robert C Jennings
In-Reply-To: <1382970051-8251-1-git-send-email-rcj@linux.vnet.ibm.com>
Simple fixes for sparse warnings in this file.
Resolves:
arch/powerpc/mm/numa.c:198:24:
warning: Using plain integer as NULL pointer
arch/powerpc/mm/numa.c:1157:5:
warning: symbol 'hot_add_node_scn_to_nid' was not declared.
Should it be static?
arch/powerpc/mm/numa.c:1238:28:
warning: Using plain integer as NULL pointer
arch/powerpc/mm/numa.c:1538:6:
warning: symbol 'topology_schedule_update' was not declared.
Should it be static?
Signed-off-by: Robert C Jennings <rcj@linux.vnet.ibm.com>
---
v1 -> v2: No changes in this patch
---
arch/powerpc/mm/numa.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index c916127..33d6784 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -195,7 +195,7 @@ static const __be32 *of_get_usable_memory(struct device_node *memory)
u32 len;
prop = of_get_property(memory, "linux,drconf-usable-memory", &len);
if (!prop || len < sizeof(unsigned int))
- return 0;
+ return NULL;
return prop;
}
@@ -1154,7 +1154,7 @@ static int hot_add_drconf_scn_to_nid(struct device_node *memory,
* represented in the device tree as a node (i.e. memory@XXXX) for
* each memblock.
*/
-int hot_add_node_scn_to_nid(unsigned long scn_addr)
+static int hot_add_node_scn_to_nid(unsigned long scn_addr)
{
struct device_node *memory;
int nid = -1;
@@ -1235,7 +1235,7 @@ static u64 hot_add_drconf_memory_max(void)
struct device_node *memory = NULL;
unsigned int drconf_cell_cnt = 0;
u64 lmb_size = 0;
- const __be32 *dm = 0;
+ const __be32 *dm = NULL;
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
if (memory) {
@@ -1535,7 +1535,7 @@ static void topology_work_fn(struct work_struct *work)
}
static DECLARE_WORK(topology_work, topology_work_fn);
-void topology_schedule_update(void)
+static void topology_schedule_update(void)
{
schedule_work(&topology_work);
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: Move local setup.h declarations to arch includes
From: Robert Jennings @ 2013-10-28 14:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20131028012819.GB8331@concordia>
* Michael Ellerman (michael@ellerman.id.au) wrote:
> On Fri, Oct 25, 2013 at 02:25:07PM -0500, Robert C Jennings wrote:
> > Move the few declarations from arch/powerpc/kernel/setup.h
> > into arch/powerpc/include/asm/setup.h. This resolves a
> > sparse warning for arch/powerpc/mm/numa.c which defines
> > do_init_bootmem() but can't include the setup.h header
> > in the prior path.
> >
> > Resolves:
> > arch/powerpc/mm/numa.c:998:13:
> > warning: symbol 'do_init_bootmem' was not declared.
> > Should it be static?
>
> There's always a tension between too many well-focused-micro-headers,
> and too few random-piles-of-junk headers. I tend towards the former, but
> in this case I think you're right to drop setup.h.
>
> > diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
> > index d3ca855..5e24df0 100644
> > --- a/arch/powerpc/include/asm/setup.h
> > +++ b/arch/powerpc/include/asm/setup.h
> > @@ -23,6 +23,11 @@ extern void reloc_got2(unsigned long);
> >
> > #define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x)))
> >
> > +extern void check_for_initrd(void);
> > +extern void do_init_bootmem(void);
> > +extern void setup_panic(void);
> > +extern int do_early_xmon;
>
> I don't see do_early_xmon used anywhere? Looks like I forgot to clean it
> up in 47679283. Mind dropping it?
>
> I think these days it's trendy to not use extern in headers.
>
> cheers
I'll clean that up and send again.
-Rob
^ permalink raw reply
* Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group
From: Peter Zijlstra @ 2013-10-28 13:50 UTC (permalink / raw)
To: Preeti U Murthy
Cc: Michael Neuling, Vincent Guittot, Mike Galbraith, linuxppc-dev,
linux-kernel, Anton Blanchard, Paul Turner, Ingo Molnar
In-Reply-To: <5268D54A.9060604@linux.vnet.ibm.com>
On Thu, Oct 24, 2013 at 01:37:38PM +0530, Preeti U Murthy wrote:
> kernel/sched/core.c | 5 +++++
> kernel/sched/fair.c | 38 ++++++++++++++++++++------------------
> kernel/sched/sched.h | 1 +
> 3 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c06b8d3..c540392 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5271,6 +5271,7 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
> DEFINE_PER_CPU(int, sd_llc_size);
> DEFINE_PER_CPU(int, sd_llc_id);
> DEFINE_PER_CPU(struct sched_domain *, sd_numa);
> +DEFINE_PER_CPU(struct sched_domain *, sd_busy);
>
> static void update_top_cache_domain(int cpu)
> {
> @@ -5290,6 +5291,10 @@ static void update_top_cache_domain(int cpu)
>
> sd = lowest_flag_domain(cpu, SD_NUMA);
> rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
> +
> + sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
> + if (sd)
> + rcu_assign_pointer(per_cpu(sd_busy, cpu), sd->parent);
> }
>
> /*
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e9c9549..f66cfd9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6515,16 +6515,16 @@ static inline void nohz_balance_exit_idle(int cpu)
> static inline void set_cpu_sd_state_busy(void)
> {
> struct sched_domain *sd;
> + int cpu = smp_processor_id();
>
> rcu_read_lock();
> + sd = rcu_dereference(per_cpu(sd_busy, cpu));
>
> if (!sd || !sd->nohz_idle)
> goto unlock;
> sd->nohz_idle = 0;
>
> + atomic_inc(&sd->groups->sgp->nr_busy_cpus);
> unlock:
> rcu_read_unlock();
> }
> @@ -6532,16 +6532,16 @@ unlock:
> void set_cpu_sd_state_idle(void)
> {
> struct sched_domain *sd;
> + int cpu = smp_processor_id();
>
> rcu_read_lock();
> + sd = rcu_dereference(per_cpu(sd_busy, cpu));
>
> if (!sd || sd->nohz_idle)
> goto unlock;
> sd->nohz_idle = 1;
>
> + atomic_dec(&sd->groups->sgp->nr_busy_cpus);
> unlock:
> rcu_read_unlock();
> }
Oh nice, that gets rid of the multiple atomics, and it nicely splits
this nohz logic into per topology groups -- now if only we could split
the rest too :-)
> @@ -6748,6 +6748,8 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
> {
> unsigned long now = jiffies;
> struct sched_domain *sd;
> + struct sched_group_power *sgp;
> + int nr_busy;
>
> if (unlikely(idle_cpu(cpu)))
> return 0;
> @@ -6773,22 +6775,22 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
> goto need_kick;
>
> rcu_read_lock();
> + sd = rcu_dereference(per_cpu(sd_busy, cpu));
>
> + if (sd) {
> + sgp = sd->groups->sgp;
> + nr_busy = atomic_read(&sgp->nr_busy_cpus);
>
> + if (nr_busy > 1)
> goto need_kick_unlock;
> }
OK, so far so good.
> +
> + sd = highest_flag_domain(cpu, SD_ASYM_PACKING);
> +
> + if (sd && (cpumask_first_and(nohz.idle_cpus_mask,
> + sched_domain_span(sd)) < cpu))
> + goto need_kick_unlock;
> +
> rcu_read_unlock();
> return 0;
This again is a bit sad; most archs will not have SD_ASYM_PACKING set at
all; this means that they all will do a complete (and pointless) sched
domain tree walk here.
It would be much better to also introduce sd_asym and do the analogous
thing to the new sd_busy.
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-10-28 13:26 UTC (permalink / raw)
To: Victor Kaplansky
Cc: Michael Neuling, Mathieu Desnoyers, Frederic Weisbecker, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard, Paul McKenney
In-Reply-To: <OFB9096CCA.68AAFFFB-ON42257C12.0044F107-42257C12.00457129@il.ibm.com>
On Mon, Oct 28, 2013 at 02:38:29PM +0200, Victor Kaplansky wrote:
> > 2013/10/25 Peter Zijlstra <peterz@infradead.org>:
> > > On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
> > > I would argue for
> > >
> > > READ ->data_tail READ ->data_head
> > > smp_rmb() (A) smp_rmb() (C)
> > > WRITE $data READ $data
> > > smp_wmb() (B) smp_mb() (D)
> > > STORE ->data_head WRITE ->data_tail
> > >
> > > Where A pairs with D, and B pairs with C.
> > >
> > > I don't think A needs to be a full barrier because we won't in fact
> > > write data until we see the store from userspace. So we simply don't
> > > issue the data WRITE until we observe it.
> > >
> > > OTOH, D needs to be a full barrier since it separates the data READ from
> > > the tail WRITE.
> > >
> > > For B a WMB is sufficient since it separates two WRITEs, and for C an
> > > RMB is sufficient since it separates two READs.
<snip>
> I think you have a point :) IMO, memory barrier (A) is superfluous.
> At producer side we need to ensure that "WRITE $data" is not committed
> to memory before "READ ->data_tail" had seen a new value and if the
> old one indicated that there is no enough space for a new entry. All
> this is already guaranteed by control flow dependancy on single CPU -
> writes will not be committed to the memory if read value of
> "data_tail" doesn't specify enough free space in the ring buffer.
>
> Likewise, on consumer side, we can make use of natural data dependency and
> memory ordering guarantee for single CPU and try to replace "smp_mb" by
> a more light-weight "smp_rmb":
>
> READ ->data_tail READ ->data_head
> // ... smp_rmb() (C)
> WRITE $data READ $data
> smp_wmb() (B) smp_rmb() (D)
> READ $header_size
> STORE ->data_head WRITE ->data_tail = $old_data_tail +
> $header_size
>
> We ensure that all $data is read before "data_tail" is written by
> doing "READ $header_size" after all other data is read and we rely on
> natural data dependancy between "data_tail" write and "header_size"
> read.
I'm not entirely sure I get the $header_size trickery; need to think
more on that. But yes, I did consider the other one. However, I had
trouble having no pairing barrier for (D).
ISTR something like Alpha being able to miss the update (for a long
while) if you don't issue the RMB.
Lets add Paul and Oleg to the thread; this is getting far more 'fun'
that it should be ;-)
For completeness; below the patch as I had queued it.
---
Subject: perf: Fix perf ring buffer memory ordering
From: Peter Zijlstra <peterz@infradead.org>
Date: Mon Oct 28 13:55:29 CET 2013
The PPC64 people noticed a missing memory barrier and crufty old
comments in the perf ring buffer code. So update all the comments and
add the missing barrier.
When the architecture implements local_t using atomic_long_t there
will be double barriers issued; but short of introducing more
conditional barrier primitives this is the best we can do.
Cc: anton@samba.org
Cc: benh@kernel.crashing.org
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: michael@ellerman.id.au
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Reported-by: Victor Kaplansky <victork@il.ibm.com>
Tested-by: Victor Kaplansky <victork@il.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lan
---
include/uapi/linux/perf_event.h | 12 +++++++-----
kernel/events/ring_buffer.c | 29 ++++++++++++++++++++++++++---
2 files changed, 33 insertions(+), 8 deletions(-)
Index: linux-2.6/include/uapi/linux/perf_event.h
===================================================================
--- linux-2.6.orig/include/uapi/linux/perf_event.h
+++ linux-2.6/include/uapi/linux/perf_event.h
@@ -479,13 +479,15 @@ struct perf_event_mmap_page {
/*
* Control data for the mmap() data buffer.
*
- * User-space reading the @data_head value should issue an rmb(), on
- * SMP capable platforms, after reading this value -- see
- * perf_event_wakeup().
+ * User-space reading the @data_head value should issue an smp_rmb(),
+ * after reading this value.
*
* When the mapping is PROT_WRITE the @data_tail value should be
- * written by userspace to reflect the last read data. In this case
- * the kernel will not over-write unread data.
+ * written by userspace to reflect the last read data, after issueing
+ * an smp_mb() to separate the data read from the ->data_tail store.
+ * In this case the kernel will not over-write unread data.
+ *
+ * See perf_output_put_handle() for the data ordering.
*/
__u64 data_head; /* head in the data section */
__u64 data_tail; /* user-space written tail */
Index: linux-2.6/kernel/events/ring_buffer.c
===================================================================
--- linux-2.6.orig/kernel/events/ring_buffer.c
+++ linux-2.6/kernel/events/ring_buffer.c
@@ -87,10 +87,31 @@ static void perf_output_put_handle(struc
goto out;
/*
- * Publish the known good head. Rely on the full barrier implied
- * by atomic_dec_and_test() order the rb->head read and this
- * write.
+ * Since the mmap() consumer (userspace) can run on a different CPU:
+ *
+ * kernel user
+ *
+ * READ ->data_tail READ ->data_head
+ * smp_rmb() (A) smp_rmb() (C)
+ * WRITE $data READ $data
+ * smp_wmb() (B) smp_mb() (D)
+ * STORE ->data_head WRITE ->data_tail
+ *
+ * Where A pairs with D, and B pairs with C.
+ *
+ * I don't think A needs to be a full barrier because we won't in fact
+ * write data until we see the store from userspace. So we simply don't
+ * issue the data WRITE until we observe it.
+ *
+ * OTOH, D needs to be a full barrier since it separates the data READ
+ * from the tail WRITE.
+ *
+ * For B a WMB is sufficient since it separates two WRITEs, and for C
+ * an RMB is sufficient since it separates two READs.
+ *
+ * See perf_output_begin().
*/
+ smp_wmb();
rb->user_page->data_head = head;
/*
@@ -154,6 +175,8 @@ int perf_output_begin(struct perf_output
* Userspace could choose to issue a mb() before updating the
* tail pointer. So that all reads will be completed before the
* write is issued.
+ *
+ * See perf_output_put_handle().
*/
tail = ACCESS_ONCE(rb->user_page->data_tail);
smp_rmb();
^ permalink raw reply
* [PATCH] warning: symbol value 'm' invalid for MCU_MPC8349EMITX
From: Christian Kujau @ 2013-10-28 12:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven
Hi,
during "make ppc6xx_defconfig" the following happens:
HOSTCC scripts/basic/fixdep
GEN /usr/local/src/tmp/lnx/Makefile
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
arch/powerpc/configs/ppc6xx_defconfig:74:warning: symbol value 'm' invalid for MCU_MPC8349EMITX
Setting CONFIG_MCU_MPC8349EMITX=y in ppc6xx_defconfig makes the warning
go away. This too has been reported by Geert Uytterhoeven a long time ago:
https://lkml.org/lkml/2011/11/13/11 - I only came across this because I
needed a "clean" defconfig for this Powerbook G5.
Signed-off-by: Christian Kujau <lists@nerdbynature.de>
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 20ebfaf..c2353bf 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -71,7 +71,7 @@ CONFIG_QUICC_ENGINE=y
CONFIG_QE_GPIO=y
CONFIG_PPC_BESTCOMM=y
CONFIG_GPIO_MPC8XXX=y
-CONFIG_MCU_MPC8349EMITX=m
+CONFIG_MCU_MPC8349EMITX=y
CONFIG_HIGHMEM=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
Christian.
--
BOFH excuse #312:
incompatible bit-registration operators
^ permalink raw reply related
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