Re: [PATCH] ASoC: imx-ssi: add check on platform_get_irq return value

[Nicolin Chen]

On Fri, Jun 30, 2017 at 05:17:35PM -0500, Gustavo A. R. Silva wrote:
> Check return value from call to platform_get_irq(),
> so in case of failure print error message and propagate
> the return value.
> 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Nicolin Chen 

Thanks

> ---
>  sound/soc/fsl/imx-ssi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
> index b95132e..0679061 100644
> --- a/sound/soc/fsl/imx-ssi.c
> +++ b/sound/soc/fsl/imx-ssi.c
> @@ -527,6 +527,10 @@ static int imx_ssi_probe(struct platform_device *pdev)
>   }
>  
>   ssi->irq = platform_get_irq(pdev, 0);
> + if (ssi->irq < 0) {
> + dev_err(>dev, "Failed to get IRQ: %d\n", ssi->irq);
> + return ssi->irq;
> + }
>  
>   ssi->clk = devm_clk_get(>dev, NULL);
>   if (IS_ERR(ssi->clk)) {
> -- 
> 2.5.0
> 

Re: [PATCH v5 3/7] powerpc/64s: Blacklist system_call() and system_call_common() from kprobes

[Michael Ellerman]

"Naveen N. Rao"  writes:

> Convert some of the symbols into private symbols and blacklist
> system_call_common() and system_call() from kprobes. We can't take a
> trap at parts of these functions as either MSR_RI is unset or the kernel
> stack pointer is not yet setup.
>
> Reviewed-by: Masami Hiramatsu 
> Reviewed-by: Nicholas Piggin 
> Signed-off-by: Naveen N. Rao 
> ---
>  arch/powerpc/kernel/entry_64.S | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index da9486e2fd89..ef8e6615b8ba 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -52,12 +52,11 @@ exception_marker:
>   .section".text"
>   .align 7
>  
> - .globl system_call_common
> -system_call_common:
> +_GLOBAL(system_call_common)

Looks good.

Yet ...

Power6:

  [0.313058] Bad kernel stack pointer 7fffdd061cf0 at c000cd80
  [0.313068] Oops: Bad kernel stack pointer, sig: 6 [#1]
  [0.313072] SMP NR_CPUS=2048 
  [0.313072] NUMA 
  [0.313076] pSeries
  [0.313081] Modules linked in:
  [0.313087] CPU: 1 PID: 1 Comm: init Not tainted 
4.12.0-rc3-gcc_ubuntu_be-g464970a #1
  [0.313093] task: c0004948 task.stack: c000494c
  [0.313097] NIP: c000cd80 LR: 7fff8e8a13b0 CTR: 
7fff8e8a1370
  [0.313103] REGS: c7fa3d40 TRAP: 0300   Not tainted  
(4.12.0-rc3-gcc_ubuntu_be-g464970a)
  [0.313108] MSR: 80001032 
  [0.313114]   CR: 8422  XER: 
  [0.313120] CFAR: 87c0 DAR: 1e64 DSISR: 4200 
SOFTE: 0 
  [0.313120] GPR00: 002d 7fffdd061cf0 7fff8e8c8af8 
 
  [0.313120] GPR04: 19c0 7fff8e86 0001 
7fff8e8c2a30 
  [0.313120] GPR08: 493e1528  b0001032 
7fff8e8a1ea8 
  [0.313120] GPR12: 8000d032 c6b30500  
 
  [0.313120] GPR16:    
 
  [0.313120] GPR20:   0080 
0001 
  [0.313120] GPR24:  7fffdd0626c9 493a0040 
0009 
  [0.313120] GPR28: 7fff8e8bfe58 7fff8e8bfb88 7fff8e8bfe40 
7fff8e8c0148 
  [0.313190] NIP [c000cd80] .load_up_vsx+0x1c/0x2c
  [0.313195] LR [7fff8e8a13b0] 0x7fff8e8a13b0
  [0.313199] Call Trace:
  [0.313201] Instruction dump:
  [0.313206] 7fe721ce 1604 38800200 7c0439ce 4e800020 71852000 41a2f7c5 
75850200 
  [0.313217] 41a2fd71 e88d0250 388419c0 38c1 <90c404a4> 658c0080 
f9810178 4bffefc4 
  [0.313229] ---[ end trace 3ca7930ed36d9399 ]---

Power7:

  [1.770801] Bad kernel stack pointer ff9be8b0 at 1f7f79590
  [1.770811] Oops: Bad kernel stack pointer, sig: 6 [#1]
  [1.770814] SMP NR_CPUS=2048 
  [1.770815] NUMA 
  [1.770819] pSeries
  [1.770825] Modules linked in:
  [1.770832] CPU: 26 PID: 1 Comm: init Not tainted 4.12.0-rc3-gcc6-g464970a 
#1
  [1.770838] task: c00e1830 task.stack: c00e1838
  [1.770843] NIP: 0001f7f79590 LR: f7f79358 CTR: 
0001f7f79590
  [1.770848] REGS: ced47d40 TRAP: 0400   Not tainted  
(4.12.0-rc3-gcc6-g464970a)
  [1.770853] MSR: 800040001032 
  [1.770860]   CR: 24000888  XER: 2000
  [1.770866] CFAR: 87c0 SOFTE: 0 
  [1.770866] GPR00: f7f7998c ff9be8b0  
 
  [1.770866] GPR04: f7f9f5b8 0005 0072 
0072 
  [1.770866] GPR08: feff  0001f7f79590 
f7f7ac30 
  [1.770866] GPR12: 0001 cec08200 0001 
 
  [1.770866] GPR16: ff9bed49  dc0065c2 
 
  [1.770866] GPR20: 2000 0064 0001 
0001 
  [1.770866] GPR24: 0001 0001 f7f62b40 
20620034 
  [1.770866] GPR28: 000a ff9bed49 f7f9fff4 
f7f9f308 
  [1.770929] NIP [0001f7f79590] 0x1f7f79590
  [1.770933] LR [f7f79358] 0xf7f79358
  [1.770937] Call Trace:
  [1.770940] Instruction dump:
  [1.770945]        
 
  [1.770953]        
 
  [1.770964] ---[ end trace 4eb52706b24fb9c6 ]---

Cell:

  [   21.359058] init[1]: unhandled signal 11 at  nip  lr 
c000b01c code 30001
  [   

[PATCH] ASoC: imx-ssi: add check on platform_get_irq return value

[Gustavo A. R. Silva]

Check return value from call to platform_get_irq(),
so in case of failure print error message and propagate
the return value.

Signed-off-by: Gustavo A. R. Silva 
---
 sound/soc/fsl/imx-ssi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index b95132e..0679061 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -527,6 +527,10 @@ static int imx_ssi_probe(struct platform_device *pdev)
}
 
ssi->irq = platform_get_irq(pdev, 0);
+   if (ssi->irq < 0) {
+   dev_err(>dev, "Failed to get IRQ: %d\n", ssi->irq);
+   return ssi->irq;
+   }
 
ssi->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(ssi->clk)) {
-- 
2.5.0

[PATCH v2] powerpc/powernv: Tell OPAL about our MMU mode on POWER9

[Michael Neuling]

From: Benjamin Herrenschmidt 

That will allow OPAL to configure the CPU in an optimal way.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Neuling 
---
v2:
  - Always set the hash bit since we always need hash for KVM guests.
  - Gate with ARCH_300 since this can break P8.
---
 arch/powerpc/include/asm/opal-api.h|  9 +
 arch/powerpc/platforms/powernv/opal.c  | 19 +--
 arch/powerpc/platforms/powernv/setup.c | 11 ++-
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0b543f0f54..b3111c14f8 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -876,6 +876,15 @@ struct OpalIoPhb4ErrorData {
 enum {
OPAL_REINIT_CPUS_HILE_BE= (1 << 0),
OPAL_REINIT_CPUS_HILE_LE= (1 << 1),
+
+   /* These two define the base MMU mode of the host on P9
+*
+* On P9 Nimbus DD2.0 and Cumlus (and later), KVM can still
+* create hash guests in "radix" mode with care (full core
+* switch only).
+*/
+   OPAL_REINIT_CPUS_MMU_HASH   = (1 << 2),
+   OPAL_REINIT_CPUS_MMU_RADIX  = (1 << 3),
 };
 
 typedef struct oppanel_line {
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 59684b4af4..eaefae10bd 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -59,6 +59,8 @@ static struct task_struct *kopald_tsk;
 
 void opal_configure_cores(void)
 {
+   uint64_t reinit_flags = 0;
+
/* Do the actual re-init, This will clobber all FPRs, VRs, etc...
 *
 * It will preserve non volatile GPRs and HSPRG0/1. It will
@@ -66,11 +68,24 @@ void opal_configure_cores(void)
 * but it might clobber a bunch.
 */
 #ifdef __BIG_ENDIAN__
-   opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_BE);
+   reinit_flags |= OPAL_REINIT_CPUS_HILE_BE;
 #else
-   opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_LE);
+   reinit_flags |= OPAL_REINIT_CPUS_HILE_LE;
 #endif
 
+   /*
+* POWER9 always support running hash:
+*  ie. Host hash  supports  hash guests
+*  Host radix supports  hash/radix guests
+*/
+   if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+   reinit_flags |= OPAL_REINIT_CPUS_MMU_HASH;
+   if (early_radix_enabled())
+   reinit_flags |= OPAL_REINIT_CPUS_MMU_RADIX;
+   }
+
+   opal_reinit_cpus(reinit_flags);
+
/* Restore some bits */
if (cur_cpu_spec->cpu_restore)
cur_cpu_spec->cpu_restore();
diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index 2dc7e5fb86..7d2723429d 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -225,6 +225,8 @@ static void pnv_kexec_wait_secondaries_down(void)
 
 static void pnv_kexec_cpu_down(int crash_shutdown, int secondary)
 {
+   uint64_t reinit_flags;
+
if (xive_enabled())
xive_kexec_teardown_cpu(secondary);
else
@@ -254,8 +256,15 @@ static void pnv_kexec_cpu_down(int crash_shutdown, int 
secondary)
 * We might be running as little-endian - now that interrupts
 * are disabled, reset the HILE bit to big-endian so we don't
 * take interrupts in the wrong endian later
+*
+* We reinit to enable both radix and hash on P9 to ensure
+* the mode used by the next kernel is always supported.
 */
-   opal_reinit_cpus(OPAL_REINIT_CPUS_HILE_BE);
+   reinit_flags = OPAL_REINIT_CPUS_HILE_BE;
+   if (cpu_has_feature(CPU_FTR_ARCH_300))
+   reinit_flags |= OPAL_REINIT_CPUS_MMU_RADIX |
+   OPAL_REINIT_CPUS_MMU_HASH;
+   opal_reinit_cpus(reinit_flags);
}
 }
 #endif /* CONFIG_KEXEC_CORE */
-- 
2.11.0

Re: [linux-next] cpus stalls detected few hours after booting next kernel

[Paul E. McKenney]

On Fri, Jun 30, 2017 at 05:28:02PM +1000, Nicholas Piggin wrote:
> On Fri, 30 Jun 2017 10:52:18 +0530
> Abdul Haleem  wrote:
> 
> > On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote:
> > > On Thu, 29 Jun 2017 20:23:05 +1000
> > > Nicholas Piggin  wrote:
> > > 
> > > > On Thu, 29 Jun 2017 19:36:14 +1000
> > > > Nicholas Piggin  wrote:
> > > 
> > > > > I don't *think* the replay-wakeup-interrupt patch is directly 
> > > > > involved, but
> > > > > it's likely to be one of the idle patches.  
> > > 
> > > Okay this turned out to be misconfigured sleep states I added for the
> > > simulator, sorry for the false alarm.
> > > 
> > > > Although you have this in the backtrace. I wonder if that's a stuck
> > > > lock in rcu_process_callbacks?
> > > 
> > > So this spinlock becomes top of the list of suspects. Can you try
> > > enabling lockdep and try to reproduce it?
> > 
> > Yes, recreated again with CONFIG_LOCKDEP=y & CONFIG_DEBUG_LOCKDEP=y set.
> > I do not see any difference in trace messages with and without LOCKDEP
> > enabled.
> > 
> > Please find the attached log file.
> 
> Can you get an rcu_invoke_callback event trace that Paul suggested?
> 
> Does this bug show up with just the powerpc next branch?

And I must say that those RCU CPU stall warnings are spectacular!

Did you by chance boot with a small subset of the CPUs online, and
bring the rest online later on?

Thanx, Paul

Re: [PATCH 1/2] powerpc/tm: fix live state of vs0/32 in tm_reclaim

[Breno Leitao]

Thanks Gustavo for the patch.

On Thu, Jun 29, 2017 at 08:39:23PM -0400, Gustavo Romero wrote:
> Currently tm_reclaim() can return with a corrupted vs0 (fp0) or vs32 (v0)
> due to the fact vs0 is used to save FPSCR and vs32 is used to save VSCR.
> 
> Later, we recheckpoint trusting that the live state of FP and VEC are ok
> depending on the MSR.FP and MSR.VEC bits, i.e. if MSR.FP is enabled that
> means the FP registers checkpointed before entering are correct and so
> after a treclaim. we can trust the FP live state, and similarly on VEC regs.
> However if tm_reclaim() does not return a sane state then tm_recheckpoint()
> will recheckpoint a corrupted instate back to the checkpoint area.
> 
> That commit fixes the corruption by restoring vs0 and vs32 from the
> ckfp_state and ckvr_state after they are used to save FPSCR and VSCR,
> respectively.
> 
> The effect of the issue described above is observed, for instance, once a
> VSX unavailable exception is caught in the middle of a transaction with
> MSR.FP = 1 or MSR.VEC = 1. If MSR.FP = 1, then after getting back to user
> space FP state is corrupted. If MSR.VEC = 1, then VEC state is corrupted.
> 
> The issue does occur if MSR.FP = 0 and MSR.VEC = 0 because ckfp_state and
> ckvr_state are both copied from fp_state and vr_state, respectively, and
> on recheckpointing both states will be restored from these thread
> structures and not from the live state.

Just complementing what Gustavo said, currently the tm_recheckpoint()
function grabs the values to be re-checkpoint from two places, depending
on the MSR configuration.

If VEC or FP are disabled on MSR argument when tm_recheckpoint() is
called, then it restorese the values from the thread ckvr/ckfp area and
recheckpoint these values into processor transactional area.

On the other side, if VEC or FP are disabled, it does not restore the
vectors and fp registers from the thread ckvec/ckfp area, and it will
recheckpoint what is currently on the live registers. If the registers
changed after the reclaim, we will send these new values recheckpointed,
and later on userspace when the transaction fails.

This second scenario is what is causing the error reported on this
email thread. In fact, I am wondering if we can hit another hidden bug that
changes the fp and vec values between the tm_reclaim() and
tm_recheckpoint() invokations, as for example, an interrupt that calls
memcpy() in this small mean time.

That said, I am wondering if we shouldn't always rely on thread ckfp and
ckvec during tm_recheckpoint() (and never rely on the live registers). This
should simplify the reclaim/recheckpoint mechanism, and make it less
error prone.

Re: [1/3] cpuidle: powerpc: cpuidle set polling before enabling irqs

[Rafael J. Wysocki]

On Fri, Jun 30, 2017 at 5:45 AM, Michael Ellerman  wrote:
> "Rafael J. Wysocki"  writes:
>
>> On Thu, Jun 29, 2017 at 2:21 PM, Michael Ellerman
>>  wrote:
>>> On Wed, 2017-06-14 at 13:02:39 UTC, Nicholas Piggin wrote:
 local_irq_enable can cause interrupts to be taken which could
 take significant amount of processing time. The idle process
 should set its polling flag before this, so another process that
 wakes it during this time will not have to send an IPI.

 Expand the TIF_POLLING_NRFLAG coverage to as large as possible.

 Reviewed-by: Gautham R. Shenoy 
 Signed-off-by: Nicholas Piggin 
>>>
>>> Series applied to powerpc next, thanks.
>>>
>>> https://git.kernel.org/powerpc/c/3fc5ee927ff4ffed6aa2fcd44d2fbf
>>
>> OK
>>
>> I've applied it too, so I guess I should drop it?
>
> Erk sorry. I hadn't heard anything so I picked it up.
>
> If you can drop it that would be good, but if not git will probably work
> it out mostly :)

I've dropped it, no problem.

Thanks,
Rafael

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

[Tejun Heo]

Hello, Michael.

On Fri, Jun 30, 2017 at 11:08:22AM +1000, Michael Ellerman wrote:
> Tejun Heo  writes:
> 
> > Could be the same problem as the one reported in the following thread.
> >
> >  http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.ibm.com
> >
> > The root cause there is ppc arch code not setting up possible cpu <->
> > numa mapping during boot.
> 
> Huh?
> 
> You changed the workqueue code to avoid that in 2186d9f940b6
> ("workqueue: move wq_numa_init() to workqueue_init()"), didn't you?

That was a different issue.  This one is cpu <-> numa node mapping not
being stable across cpu hotplug.

Thanks.

-- 
tejun

[PATCH v1 2/2] 44x/fsp2: enable eMMC arasan for fsp2 platform

[Ivan Mikhaylov]

Add mmc0 changes for enabling arasan emmc and change
defconfig appropriately.

Signed-off-by: Ivan Mikhaylov 
---
 arch/powerpc/boot/dts/fsp2.dts  |   33 +-
 arch/powerpc/configs/44x/fsp2_defconfig |2 +
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsp2.dts b/arch/powerpc/boot/dts/fsp2.dts
index 475953a..6a63026 100644
--- a/arch/powerpc/boot/dts/fsp2.dts
+++ b/arch/powerpc/boot/dts/fsp2.dts
@@ -52,6 +52,7 @@
clocks {
mmc_clk: mmc_clk {
compatible = "fixed-clock";
+   #clock-cells = <0>;
clock-frequency = <5000>;
clock-output-names = "mmc_clk";
};
@@ -359,20 +360,6 @@
interrupts = <31 0x4 15 0x84>;
};
 
-   mmc0: sdhci@020c {
-   compatible  = "st,sdhci-stih407", "st,sdhci";
-   status  = "disabled";
-   reg = <0x020c 0x2>;
-   reg-names   = "mmc";
-   interrupt-parent = <_3>;
-   interrupts  = <21 0x4 22 0x4>;
-   interrupt-names = "mmcirq";
-   pinctrl-names   = "default";
-   pinctrl-0   = <>;
-   clock-names = "mmc";
-   clocks  = <_clk>;
-   };
-
plb6 {
compatible = "ibm,plb6";
#address-cells = <2>;
@@ -501,6 +488,24 @@
 /*RXDE*/  4 _2 13 0x4>;
};
 
+   mmc0: sdhci@020c {
+   compatible  = "st,sdhci-stih407", "st,sdhci";
+   reg = <0x020c 0x2>;
+   reg-names   = "mmc";
+   interrupts  = <21 0x4>;
+   interrupt-parent = <_3>;
+   interrupt-names = "mmcirq";
+   pinctrl-names   = "default";
+   pinctrl-0   = <>;
+   clock-names = "mmc";
+   clocks  = <_clk>;
+   bus-width   = <4>;
+   non-removable;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
+   sd-uhs-ddr50;
+   };
+
opb {
compatible = "ibm,opb";
#address-cells = <1>;
diff --git a/arch/powerpc/configs/44x/fsp2_defconfig 
b/arch/powerpc/configs/44x/fsp2_defconfig
index e8e6a69..935aabe 100644
--- a/arch/powerpc/configs/44x/fsp2_defconfig
+++ b/arch/powerpc/configs/44x/fsp2_defconfig
@@ -92,8 +92,10 @@ CONFIG_MMC_DEBUG=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_OF_ARASAN=y
+CONFIG_MMC_SDHCI_ST=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_M41T80=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
-- 
1.7.1

[PATCH v1 0/2] add eMMC support for fsp2 board

[Ivan Mikhaylov]

fsp2 based on powerpc 476fpe using eMMC arasan, so we added support
of this inside our dts and also enabled via additional
dependence for sdhci-st driver in Kconfig.

this code depends on commit c4b56b023daa91953e9ebe91143e6ca156f0bcb7
which is located in powerpc linux tree in 'next' branch.

Ivan Mikhaylov (2):
  mmc/host: add FSP2(ppc476fpe) into depends for sdhci-st
  44x/fsp2: enable eMMC arasan for fsp2 platform

 arch/powerpc/boot/dts/fsp2.dts  |   33 +-
 arch/powerpc/configs/44x/fsp2_defconfig |2 ++
 drivers/mmc/host/Kconfig|2 +-
 3 files changed, 22 insertions(+), 15 deletions(-)

[PATCH v1 1/2] mmc/host: add FSP2(ppc476fpe) into depends for sdhci-st

[Ivan Mikhaylov]

shdci-st driver can be used for ppc476 fsp2 soc.

Signed-off-by: Ivan Mikhaylov 
---
 drivers/mmc/host/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 2eb9701..edf5787 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -354,7 +354,7 @@ config MMC_MOXART
 
 config MMC_SDHCI_ST
tristate "SDHCI support on STMicroelectronics SoC"
-   depends on ARCH_STI
+   depends on ARCH_STI || FSP2
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
help
-- 
1.7.1

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

[Eryu Guan]

On Fri, Jun 30, 2017 at 08:07:02PM +1000, Michael Ellerman wrote:
> Eryu Guan  writes:
> >
> > I have to update the patch a bit to make it compile.
> 
> Sure.
> 
> >> +  WARN_ON(cpumask_empty(worker->task->cpus_allowed));
> >> +  WARN_ON(cpumask_empty(pool->attrs->cpumask));
> >
> > Seems only the last two WARN_ON were triggered.
> 
> OK thanks.
> 
> Can you try this patch and see if it changes anything? (with the debug
> still applied).

This patch fixes the crash for me. After appliying this patch (with all
other debug patches still applied), kernel didn't print any warnings or
calltraces or debug messages.

> 
> We've been trying to reproduce the bug here but haven't had any luck so far.

I'm using this reproducer:
for i in `seq 5`; do
mkfs -t ext4 -F /dev/sda5 && sleep 3 && mount /dev/sda5 /mnt/ext4 && 
umount /dev/sda5
done

Thanks,
Eryu

> 
> cheers
> 
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 4640f6d64f8b..b310ecc07e00 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -733,6 +733,8 @@ void __init setup_per_cpu_areas(void)
>   for_each_possible_cpu(cpu) {
>  __per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
>   paca[cpu].data_offset = __per_cpu_offset[cpu];
> +
> + set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
>   }
>  }
>  #endif

[GIT PULL] Please pull powerpc/linux.git powerpc-4.12-8 tag

[Michael Ellerman]

Hi Linus,

Please pull hopefully the last two powerpc fixes for 4.12.

The CXL one is larger than I'd usually send at rc7, but it fixes new
code this cycle, so better to have it working for the release. It was
actually sent a few weeks back but got blocked in testing behind another
fix that was causing issues.

We are still tracking one crash in v4.12-rc7, but only one person has
reproduced it and the commit identified by bisect doesn't touch any of
the relevant code, so I think it's 50/50 whether that commit is actually
the problem or it's some code layout / toolchain issue.

cheers

The following changes since commit 34f19ff1b5a0d11e46df479623d6936460105c9f:

  powerpc/64: Initialise thread_info for emergency stacks (2017-06-23 13:25:38 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.12-8

for you to fetch changes up to d6bd8194e2867e85ac2de63486d3b83ccfae4e62:

  powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline 
copy_to/from_user() (2017-06-26 23:25:08 +1000)


powerpc fixes for 4.12 #8

Two fixes for code we merged this cycle:

 - cxl: Fixes for Coherent Accelerator Interface Architecture 2.0
 - Avoid miscompilation w/GCC 4.6.3 on 32-bit - don't inline copy_to/from_user()

Thanks to:
  Al Viro, Larry Finger, Christophe Lombard.


Christophe Lombard (1):
  cxl: Fixes for Coherent Accelerator Interface Architecture 2.0

Michael Ellerman (1):
  powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline 
copy_to/from_user()

 arch/powerpc/include/asm/uaccess.h |  8 +---
 drivers/misc/cxl/context.c |  6 +++---
 drivers/misc/cxl/cxl.h | 18 +-
 drivers/misc/cxl/fault.c   | 23 +++
 drivers/misc/cxl/main.c| 17 +
 drivers/misc/cxl/native.c  | 29 +
 drivers/misc/cxl/pci.c | 11 ---
 7 files changed, 58 insertions(+), 54 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH] powerpc: allow compiling with GENERIC_MSI_IRQ

[Laurentiu Tudor]

Hi Michael,

On 06/30/2017 01:08 PM, Michael Ellerman wrote:
> Hi Laurentiu,
>
> laurentiu.tu...@nxp.com writes:
>> From: Laurentiu Tudor 
>>
>> This allows building powerpc with the GENERIC_MSI_IRQ Kconfig
>> by enabling the asm-generic msi.h in Kbuild. Without this,
>> there's a compilation error [1] because powerpc, as most arches,
>> doesn't provide an asm/msi.h.
>>
>> [1] In file included from ./include/linux/kvm_host.h:20:0,
>>   from ./arch/powerpc/include/asm/kvm_ppc.h:30,
>>   from arch/powerpc/kernel/dbell.c:20:
>> ./include/linux/msi.h:195:21: fatal error: asm/msi.h: No such file or 
>> directory
>
> I have >50 configs here with GENERIC_MSI_IRQ=y, so I don't understand
> what's going wrong for you.
>
> Can you tell me more about what you're doing and how it's breaking.
>

Actually i made an error in the commit message, sorry about that. It's 
GENERIC_MSI_IRQ_DOMAIN that breaks the arch/powerpc build. If this is 
enabled, the generic header include/linux/msi.h wants an asm/msi.h and 
we don't have one on powerpc. That's what the patch tries to fix.
Want me to resend with the correct commit message? ... if you're ok with 
the patch, of course.

---
Thanks & Best Regards, Laurentiu

Re: [PATCH] powerpc/64s: watchdog false positive warning at CPU unplug

[Michael Ellerman]

Nicholas Piggin  writes:

> CPU unplug will call stop_wd_on_cpu regardless if the watchdog has
> been configured to be enabled on that CPU. Don't warn in the case
> it's not in our enabled mask, this is a valid case.
>
> Fixes: powerpc-64s-implement-arch-specific-hardlockup-watchdog.patch
> Reported-by: Santosh Sivaraj 
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/kernel/watchdog.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Acked-by: Michael Ellerman 

cheers

Re: [PATCH] powerpc: allow compiling with GENERIC_MSI_IRQ

[Michael Ellerman]

Hi Laurentiu,

laurentiu.tu...@nxp.com writes:
> From: Laurentiu Tudor 
>
> This allows building powerpc with the GENERIC_MSI_IRQ Kconfig
> by enabling the asm-generic msi.h in Kbuild. Without this,
> there's a compilation error [1] because powerpc, as most arches,
> doesn't provide an asm/msi.h.
>
> [1] In file included from ./include/linux/kvm_host.h:20:0,
>  from ./arch/powerpc/include/asm/kvm_ppc.h:30,
>  from arch/powerpc/kernel/dbell.c:20:
> ./include/linux/msi.h:195:21: fatal error: asm/msi.h: No such file or 
> directory

I have >50 configs here with GENERIC_MSI_IRQ=y, so I don't understand
what's going wrong for you.

Can you tell me more about what you're doing and how it's breaking.

cheers

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

[Michael Ellerman]

Eryu Guan  writes:
>
> I have to update the patch a bit to make it compile.

Sure.

>> +WARN_ON(cpumask_empty(worker->task->cpus_allowed));
>> +WARN_ON(cpumask_empty(pool->attrs->cpumask));
>
> Seems only the last two WARN_ON were triggered.

OK thanks.

Can you try this patch and see if it changes anything? (with the debug
still applied).

We've been trying to reproduce the bug here but haven't had any luck so far.

cheers

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4640f6d64f8b..b310ecc07e00 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -733,6 +733,8 @@ void __init setup_per_cpu_areas(void)
for_each_possible_cpu(cpu) {
 __per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
paca[cpu].data_offset = __per_cpu_offset[cpu];
+
+   set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
}
 }
 #endif

[PATCH] powerpc: allow compiling with GENERIC_MSI_IRQ

[laurentiu.tudor]

From: Laurentiu Tudor 

This allows building powerpc with the GENERIC_MSI_IRQ Kconfig
by enabling the asm-generic msi.h in Kbuild. Without this,
there's a compilation error [1] because powerpc, as most arches,
doesn't provide an asm/msi.h.

[1] In file included from ./include/linux/kvm_host.h:20:0,
 from ./arch/powerpc/include/asm/kvm_ppc.h:30,
 from arch/powerpc/kernel/dbell.c:20:
./include/linux/msi.h:195:21: fatal error: asm/msi.h: No such file or directory

Signed-off-by: Laurentiu Tudor 
---
 arch/powerpc/include/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index 5c4fbc8..2542ea1 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -8,3 +8,4 @@ generic-y += mcs_spinlock.h
 generic-y += preempt.h
 generic-y += rwsem.h
 generic-y += vtime.h
+generic-y += msi.h
-- 
2.9.4

Re: [PATCH] powerpc/hugetlbfs: Export HPAGE_SHIFT

[Anshuman Khandual]

On 06/30/2017 12:22 PM, Oliver O'Halloran wrote:
> Export it so it can be referenced inside a module.
> 
> Signed-off-by: Oliver O'Halloran 
> ---
>  arch/powerpc/mm/hugetlbpage.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index ceeab69cf7fc..96293560f294 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -34,6 +34,7 @@
>  #define PAGE_SHIFT_16G   34
> 
>  unsigned int HPAGE_SHIFT;
> +EXPORT_SYMBOL(HPAGE_SHIFT);

Why would you need this in a driver ? This represents the
default HugeTLB page size.

[PATCH] powerpc/64s: watchdog false positive warning at CPU unplug

[Nicholas Piggin]

CPU unplug will call stop_wd_on_cpu regardless if the watchdog has
been configured to be enabled on that CPU. Don't warn in the case
it's not in our enabled mask, this is a valid case.

Fixes: powerpc-64s-implement-arch-specific-hardlockup-watchdog.patch
Reported-by: Santosh Sivaraj 
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/watchdog.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
index d46040c0da40..93395a53336b 100644
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -310,10 +310,8 @@ static int start_wd_on_cpu(unsigned int cpu)
 
 static int stop_wd_on_cpu(unsigned int cpu)
 {
-   if (!cpumask_test_cpu(cpu, _cpus_enabled)) {
-   WARN_ON(1);
-   return 0;
-   }
+   if (!cpumask_test_cpu(cpu, _cpus_enabled))
+   return 0; /* Can happen in CPU unplug case */
 
stop_watchdog_timer_on(cpu);
 
-- 
2.11.0

Re: [linux-next] cpus stalls detected few hours after booting next kernel

[Nicholas Piggin]

On Fri, 30 Jun 2017 10:52:18 +0530
Abdul Haleem  wrote:

> On Fri, 2017-06-30 at 00:45 +1000, Nicholas Piggin wrote:
> > On Thu, 29 Jun 2017 20:23:05 +1000
> > Nicholas Piggin  wrote:
> > 
> > > On Thu, 29 Jun 2017 19:36:14 +1000
> > > Nicholas Piggin  wrote:
> > 
> > > > I don't *think* the replay-wakeup-interrupt patch is directly involved, 
> > > > but
> > > > it's likely to be one of the idle patches.  
> > 
> > Okay this turned out to be misconfigured sleep states I added for the
> > simulator, sorry for the false alarm.
> > 
> > > Although you have this in the backtrace. I wonder if that's a stuck
> > > lock in rcu_process_callbacks?
> > 
> > So this spinlock becomes top of the list of suspects. Can you try
> > enabling lockdep and try to reproduce it?
> 
> Yes, recreated again with CONFIG_LOCKDEP=y & CONFIG_DEBUG_LOCKDEP=y set.
> I do not see any difference in trace messages with and without LOCKDEP
> enabled.
> 
> Please find the attached log file.

Can you get an rcu_invoke_callback event trace that Paul suggested?

Does this bug show up with just the powerpc next branch?

Thanks,
Nick

Re: [PATCH v5 0/7] powerpc: build out kprobes blacklist -- series 3

[Nicholas Piggin]

On Thu, 29 Jun 2017 23:19:13 +0530
"Naveen N. Rao"  wrote:

> This is the third in the series of patches to build out an appropriate
> kprobes blacklist for powerpc. Since posting the second series (*),
> there have been related changes to the code and I have brought that
> series forward to account for those changes. As such, all patches from
> the second series are included in this patchset.
> 
> This patchset now ensures that the newly added multiple kprobes test in
> the ftrace testsuite passes on powerpc64. Tested on both Elfv1 and
> Elfv2.
> 
> Changes since v4:
>   - Patch 5 changed to move system_call_exit() symbol before the mtmsrd,
> along with an explanation for its placement.
>   - Patch 7 reverted to previous version moving the new symbol before
> the mtmsrd as well.
>   - All other patches remain unchanged from v4.

These all look good to me now.

Thanks,
Nick

[PATCH] powerpc/hugetlbfs: Export HPAGE_SHIFT

[Oliver O'Halloran]

Export it so it can be referenced inside a module.

Signed-off-by: Oliver O'Halloran 
---
 arch/powerpc/mm/hugetlbpage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index ceeab69cf7fc..96293560f294 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -34,6 +34,7 @@
 #define PAGE_SHIFT_16G 34
 
 unsigned int HPAGE_SHIFT;
+EXPORT_SYMBOL(HPAGE_SHIFT);
 
 /*
  * Tracks gpages after the device tree is scanned and before the
-- 
2.9.4