Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
On Fri, 2014-11-28 at 10:53 +, David Laight wrote: From: Benjamin Herrenschmidt On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote: Can't we just unconditionally clear at as long as we do that after we've saved it ? In that case, it's just a matter for the fixup code to check the saved version rather than the actual CR.. I use CR bit setting in the interrupt return path to enter the fixup section search. If we unconditionally clear it, we will have to enter the fixup section for every kernel return nip right? As I said above. Can't we look at the saved version ? IE. - On interrupt entry: * Save CR to CCR(r1) * clear CR5 - On exit * Check CCR(r1)'s CR5 field * restore CR Actually there is no real reason why the 'fixup' can't be done during interrupt entry. Other than if we crash, we get the wrong PC in the log etc... unlikely but I tend to prefer this. Also if we ever allow something like a local atomic on a faulting (uesrspace) address, we want a precise PC on entry. Generally, we have a lot more entry path than exit path, it's easier to keep the entry path simpler. Cheers, Ben. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
KVM XICS bug
Hi,
I've been seeing intermittent hangs when booting a KVM guest on a busy box.
Both host and guest are mainline (3.18-rc6). The backtrace looks like:
INFO: rcu_sched self-detected stall on CPU { 7} (t=8404 jiffies g=-299 c=-300
q=79)
Task dump for CPU 7:
swapper/7 R running task11840 0 1 0x0804
Call Trace:
[c007fa5434a0] [c00cd684] sched_show_task+0xe4/0x160 (unreliable)
[c007fa543510] [c00fa568] rcu_dump_cpu_stacks+0xe8/0x160
[c007fa543560] [c00fe75c] rcu_check_callbacks+0x59c/0x8b0
[c007fa543680] [c0104a68] update_process_times+0x58/0xb0
[c007fa5436c0] [c0114e14] tick_periodic+0x44/0x110
[c007fa5436f0] [c0115208] tick_handle_periodic+0x38/0xc0
[c007fa543730] [c001c7cc] __timer_interrupt+0x8c/0x240
[c007fa543780] [c001ce90] timer_interrupt+0xa0/0xe0
[c007fa5437b0] [c00099f4] restore_check_irq_replay+0x54/0x70
--- interrupt: 901 at arch_local_irq_restore+0x74/0x90
LR = arch_local_irq_restore+0x74/0x90
[c007fa543aa0] [c00d1874] vtime_common_account_irq_enter+0x54/0x70
(unreliable)
[c007fa543ac0] [c009c3d8] __do_softirq+0xd8/0x3a0
[c007fa543bb0] [c009c9f8] irq_exit+0xc8/0x110
[c007fa543be0] [c001ce94] timer_interrupt+0xa4/0xe0
[c007fa543c10] [c00099f4] restore_check_irq_replay+0x54/0x70
--- interrupt: 901 at arch_local_irq_restore+0x5c/0x90
LR = arch_local_irq_restore+0x40/0x90
[c007fa543f00] [c0097864] cpu_notify+0x34/0x80 (unreliable)
[c007fa543f20] [c003afa0] start_secondary+0x330/0x360
[c007fa543f90] [c0008b6c] start_secondary_prolog+0x10/0x14
XICS in kernel emulation is disabled (I really need to update the defconfig).
It looks like we are looping in restore_check_irq_replay, replaying 0x500
exceptions. When we call H_XIRR to ask for the IRQ, QEMU tells us it's a
spurious IRQ.
Thinking up other ways to create similar stress, I ran a big SMP guest
on one core (with taskset). With no root filesystem this will just
panic and reboot until it hits the bug:
taskset -c 0 ~/qemu/ppc64-softmmu/qemu-system-ppc64 -enable-kvm -smp
cores=16,threads=8 -m 4G -M pseries -nographic -vga none -kernel vmlinux
It usually hits in under 5 minutes.
I took a QEMU trace (I added a tracepoint to power7_set_irq) and we can
see QEMU is trying to cancel the exception:
xics_icp_accept 0.322 pid=71614 old_xirr=0xff00 new_xirr=0xff00
power7_set_irq 2.232 pid=71614 pin=0x0 level=0x0
xics_icp_accept 0.285 pid=71614 old_xirr=0xff00 new_xirr=0xff00
power7_set_irq 21.809 pid=71614 pin=0x0 level=0x0
xics_icp_accept 0.311 pid=71614 old_xirr=0xff00 new_xirr=0xff00
power7_set_irq 2.230 pid=71614 pin=0x0 level=0x0
To me it looks like the KVM and the QEMU view of the 0x500 exception
state has got out of sync. The patch below fixes the issue for me, but
we might want to dig further to understand why the state has got out of
sync. Any ideas?
Anton
--
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index bec82cd..cb0911f 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -60,7 +60,6 @@ void ppc_set_irq(PowerPCCPU *cpu, int n_IRQ, int level)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = cpu-env;
-unsigned int old_pending = env-pending_interrupts;
if (level) {
env-pending_interrupts |= 1 n_IRQ;
@@ -72,11 +71,9 @@ void ppc_set_irq(PowerPCCPU *cpu, int n_IRQ, int level)
}
}
-if (old_pending != env-pending_interrupts) {
#ifdef CONFIG_KVM
-kvmppc_set_interrupt(cpu, n_IRQ, level);
+kvmppc_set_interrupt(cpu, n_IRQ, level);
#endif
-}
LOG_IRQ(%s: %p n_IRQ %d level %d = pending %08 PRIx32
req %08x\n, __func__, env, n_IRQ, level,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/8] replace memset by memzero_explicit
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)x
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
//
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)x
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// /smpl
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/8] crypto: replace memset by memzero_explicit
From: Julia Lawall ju...@diku.dk
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// /smpl
This change was suggested by Daniel Borkmann dbork...@redhat.com
Signed-off-by: Julia Lawall ju...@diku.dk
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
arch/powerpc/crypto/sha1.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/sha1.c b/arch/powerpc/crypto/sha1.c
index 0f88c7b..d3feba5 100644
--- a/arch/powerpc/crypto/sha1.c
+++ b/arch/powerpc/crypto/sha1.c
@@ -66,7 +66,7 @@ static int sha1_update(struct shash_desc *desc, const u8
*data,
src = data + done;
} while (done + 63 len);
- memset(temp, 0, sizeof(temp));
+ memzero_explicit(temp, sizeof(temp));
partial = 0;
}
memcpy(sctx-buffer + partial, src, len - done);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/8] replace memset by memzero_explicit
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)x
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
//
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)x
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// /smpl
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/8 v2] crypto: replace memset by memzero_explicit
From: Julia Lawall julia.law...@lip6.fr
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// /smpl
This change was suggested by Daniel Borkmann dbork...@redhat.com
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
v2: fixed email address
arch/powerpc/crypto/sha1.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/sha1.c b/arch/powerpc/crypto/sha1.c
index 0f88c7b..d3feba5 100644
--- a/arch/powerpc/crypto/sha1.c
+++ b/arch/powerpc/crypto/sha1.c
@@ -66,7 +66,7 @@ static int sha1_update(struct shash_desc *desc, const u8
*data,
src = data + done;
} while (done + 63 len);
- memset(temp, 0, sizeof(temp));
+ memzero_explicit(temp, sizeof(temp));
partial = 0;
}
memcpy(sctx-buffer + partial, src, len - done);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] KVM: PPC: Enable in kernel XICS emulation by default
The in kernel XICS emulation is faster than doing it all in QEMU and it has got a lot of testing, so enable it by default Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/kvm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 602eb51..f5769f1 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -172,6 +172,7 @@ config KVM_XICS depends on KVM_BOOK3S_64 !KVM_MPIC select HAVE_KVM_IRQCHIP select HAVE_KVM_IRQFD + default y ---help--- Include support for the XICS (eXternal Interrupt Controller Specification) interrupt controller architecture used on -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers. To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid num_online_nodes()); + VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); n = get_node(cachep, nodeid); BUG_ON(!n); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/3] powerpc/powernv: Replace OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE
On Wed, Nov 26, 2014 at 03:07:51PM +1100, Michael Ellerman wrote: On Mon, 2014-24-11 at 22:26:59 UTC, Gavin Shan wrote: The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE, which is translated to OPAL_DEASSERT_RESET or something else by the EEH backend accordingly. The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for ioda_eeh_phb_reset(). What is the symptom? Does it not work at all or is it just a cosmetic issue? ie. should I send this to Linus ASAP or can it wait for the next release. Looks like this went in as 361f2a2a1536 (powrpc/powernv: Reset PHB in kdump kernel) in 3.16. Should it go to stable? It's just a cosmetic issue and please pick it up for next release. Thanks, Gavin cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [3/3] powerpc/eeh: Fix missed PE#0 on P7IOC
On Wed, Nov 26, 2014 at 03:09:10PM +1100, Michael Ellerman wrote: On Mon, 2014-24-11 at 22:27:00 UTC, Gavin Shan wrote: PE#0 should be regarded as valid for P7IOC, while it's invalid for PHB3. The patch adds flag EEH_VALID_PE_ZERO to differentiate those two cases. Without the patch, we possibly see frozen PE#0 state is cleared without EEH recovery taken on P7IOC as following kernel logs indicate: This sounds like an urgent fix but I'm not sure. You can pick it up for next release. Usually, we shouldn't see errors from PE#0. Something I did to force that for testing purpose: disable memory windows of the root complex and then access one of memory BARs on one adapter behind the root complex. Thanks, Gavin cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
(2014/12/01 7:16), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers. Do you have the call trace? If you have it, please add it in the description. To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org Do you need to backport it into -stable kernels? --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid num_online_nodes()); + VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); How about use: VM_BUG_ON(!node_online(nodeid)); When allocating the memory, the node of the memory being allocated must be online. But your code cannot check the condition. Thanks, Yasuaki Ishimatsu n = get_node(cachep, nodeid); BUG_ON(!n); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: (2014/12/01 7:16), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers. Do you have the call trace? If you have it, please add it in the description. I can get it easily enough. To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org Do you need to backport it into -stable kernels? It does need to go to stable, yes, for 3.10 and later. --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; -VM_BUG_ON(nodeid num_online_nodes()); +VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); How about use: VM_BUG_ON(!node_online(nodeid)); That would not be better, since node_online() doesn't bounds-check its argument. When allocating the memory, the node of the memory being allocated must be online. But your code cannot check the condition. The following two lines: n = get_node(cachep, nodeid); BUG_ON(!n); effectively check that condition already, as I tried to explain in the commit message. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/8 v2] crypto: replace memset by memzero_explicit
On Sun, 2014-11-30 at 18:03 +0100, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr Memset on a local variable may be removed when it is called just before the variable goes out of scope. Using memzero_explicit defeats this optimization. A simplified version of the semantic patch that makes this Signed-off-by: Julia Lawall julia.law...@lip6.fr --- Daniel Borkmann suggested that these patches could go through Herbert Xu's cryptodev tree. That's fine by me: Acked-by: Michael Ellerman m...@ellerman.id.au cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
(2014/12/01 9:42), Paul Mackerras wrote: On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote: (2014/12/01 7:16), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers. Do you have the call trace? If you have it, please add it in the description. I can get it easily enough. To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid, the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org Do you need to backport it into -stable kernels? It does need to go to stable, yes, for 3.10 and later. --- diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid num_online_nodes()); + VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); How about use: VM_BUG_ON(!node_online(nodeid)); That would not be better, since node_online() doesn't bounds-check its argument. Ah. You are right. When allocating the memory, the node of the memory being allocated must be online. But your code cannot check the condition. The following two lines: n = get_node(cachep, nodeid); BUG_ON(!n); effectively check that condition already, as I tried to explain in the commit message. O.K. I understood. Thansk, Yasuaki Ishimatsu Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
irq_dispose_mapping() in turns calls unregister_irq_proc(),
which will remove irq proc entry, if IRQ is not freed
before calling of irq_dispose_mapping(), then it will cause
kernel warning.
By free IRQ before irq_dispose_mapping(), this patch fix
the following kernel warning found when remove of fsl_ssi driver:
[ 31.515336] [ cut here ]
[ 31.520091] WARNING: CPU: 2 PID: 434 at fs/proc/generic.c:521
remove_proc_entry+0x14c/0x16c()
[ 31.528708] remove_proc_entry: removing non-empty directory 'irq/79',
leaking at least '202c000.ss'
[ 31.537911] Modules linked in: snd_soc_wm8962 snd_soc_imx_wm8962
snd_soc_fsl_ssi(-) evbug
[ 31.546249] CPU: 2 PID: 434 Comm: rmmod Not tainted
3.18.0-rc6-00028-g3314bf6-dirty #1
[ 31.554235] Backtrace:
[ 31.556816] [80011ea8] (dump_backtrace) from [80012044]
(show_stack+0x18/0x1c)
[ 31.564416] r6:80142c88 r5: r4: r3:
[ 31.570267] [8001202c] (show_stack) from [806980ec]
(dump_stack+0x88/0xa4)
[ 31.577588] [80698064] (dump_stack) from [80029d78]
(warn_slowpath_common+0x70/0x94)
[ 31.585711] r5:0009 r4:bb61fd90
[ 31.589423] [80029d08] (warn_slowpath_common) from [80029e40]
(warn_slowpath_fmt+0x38/0x40)
[ 31.598187] r8:bb61fdfe r7:be05d76d r6:be05d9a8 r5:0002 r4:be05d700
[ 31.605054] [80029e0c] (warn_slowpath_fmt) from [80142c88]
(remove_proc_entry+0x14c/0x16c)
[ 31.613709] r3:806a79c0 r2:808229a0
[ 31.617371] [80142b3c] (remove_proc_entry) from [80070380]
(unregister_irq_proc+0x94/0xb8)
[ 31.625989] r10: r8:8000ede4 r7:80955f2c r6:004f r5:8118e738
r4:be00af00
[ 31.633952] [800702ec] (unregister_irq_proc) from [80069dac]
(free_desc+0x2c/0x64)
[ 31.641898] r6:004f r5:80955f38 r4:be00af00
[ 31.646604] [80069d80] (free_desc) from [80069e68]
(irq_free_descs+0x4c/0x8c)
[ 31.654092] r7:0081 r6:0001 r5:004f r4:0001
[ 31.659863] [80069e1c] (irq_free_descs) from [8006fc3c]
(irq_dispose_mapping+0x40/0x5c)
[ 31.668247] r6:be17b844 r5:be17b800 r4:004f r3:802c5ec0
[ 31.673998] [8006fbfc] (irq_dispose_mapping) from [7f004ea4]
(fsl_ssi_remove+0x58/0x70 [snd_so)
[ 31.683948] r4:bb5bba10 r3:0001
[ 31.687618] [7f004e4c] (fsl_ssi_remove [snd_soc_fsl_ssi]) from
[803720a0] (platform_drv_remove)
[ 31.697564] r5:7f0064f8 r4:be17b810
[ 31.701195] [80372080] (platform_drv_remove) from [80370494]
(__device_release_driver+0x78/0xc)
[ 31.710361] r5:7f0064f8 r4:be17b810
[ 31.713987] [8037041c] (__device_release_driver) from [80370d20]
(driver_detach+0xbc/0xc0)
[ 31.722631] r5:7f0064f8 r4:be17b810
[ 31.726259] [80370c64] (driver_detach) from [80370304]
(bus_remove_driver+0x54/0x98)
[ 31.734382] r6:0800 r5: r4:7f0064f8 r3:bb67f500
[ 31.740149] [803702b0] (bus_remove_driver) from [80371398]
(driver_unregister+0x30/0x50)
[ 31.748617] r4:7f0064f8 r3:bd9f7080
[ 31.752245] [80371368] (driver_unregister) from [80371f3c]
(platform_driver_unregister+0x14/0x)
[ 31.761498] r4:7f00655c r3:7f005a70
[ 31.765130] [80371f28] (platform_driver_unregister) from [7f005a84]
(fsl_ssi_driver_exit+0x14/)
[ 31.776147] [7f005a70] (fsl_ssi_driver_exit [snd_soc_fsl_ssi]) from
[8008ed80] (SyS_delete_mod)
[ 31.786553] [8008ec64] (SyS_delete_module) from [8000ec20]
(ret_fast_syscall+0x0/0x48)
[ 31.794824] r6:00c46d18 r5:0800 r4:00c46d18
[ 31.799530] ---[ end trace 954e8a3a15379e52 ]---
Moreover replace devm_request_irq() with request_irq() since there is
no need to use it as now driver always frees IRQ manually.
Signed-off-by: Jiada Wang jiada_w...@mentor.com
---
sound/soc/fsl/fsl_ssi.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index e695517..cfdb337 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1400,9 +1400,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
}
if (ssi_private-use_dma) {
- ret = devm_request_irq(pdev-dev, ssi_private-irq,
- fsl_ssi_isr, 0, dev_name(pdev-dev),
- ssi_private);
+ ret = request_irq(ssi_private-irq, fsl_ssi_isr, 0,
+ dev_name(pdev-dev), ssi_private);
if (ret 0) {
dev_err(pdev-dev, could not claim irq %u\n,
ssi_private-irq);
@@ -1412,7 +1411,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ret = fsl_ssi_debugfs_create(ssi_private-dbg_stats, pdev-dev);
if (ret)
- goto error_asoc_register;
+ goto error_debugfs_create;
/*
* If codec-handle property is missing from SSI node, we assume
@@ -1453,6 +1452,10 @@ done:
error_sound_card:
fsl_ssi_debugfs_remove(ssi_private-dbg_stats);
+error_debugfs_create:
+ if (ssi_private-use_dma)
+
[PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs
The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA PowerNV Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc5-kvm+ #17 task: c13ba230 ti: c1494000 task.ti: c1494000 NIP: c0264f6c LR: c0264f5c CTR: REGS: c14979a0 TRAP: 0700 Not tainted (3.18.0-rc5-kvm+) MSR: 92021032 SF,HV,VEC,ME,IR,DR,RI CR: 28000448 XER: 2000 CFAR: c047e978 SOFTE: 0 GPR00: c0264f5c c1497c20 c1499d48 0004 GPR04: 0100 0010 0068 GPR08: 0001 082d c0cca5a8 GPR12: 48000448 cfda 01003bd44ff0 10020578 GPR16: 01003bd44ff8 01003bd45000 0001 GPR20: 0010 GPR24: c00ffe80 c0c824ec 0068 c00ffe80 GPR28: 0010 c00ffe80 0010 NIP [c0264f6c] .cache_alloc_node+0x6c/0x270 LR [c0264f5c] .cache_alloc_node+0x5c/0x270 Call Trace: [c1497c20] [c0264f5c] .cache_alloc_node+0x5c/0x270 (unreliable) [c1497cf0] [c026552c] .kmem_cache_alloc_node_trace+0xdc/0x360 [c1497dc0] [c0c824ec] .init_list+0x3c/0x128 [c1497e50] [c0c827b4] .kmem_cache_init+0x1dc/0x258 [c1497ef0] [c0c54090] .start_kernel+0x2a0/0x568 [c1497f90] [c0008c6c] start_here_common+0x20/0xa8 Instruction dump: 7c7d1b78 7c962378 4bda4e91 6000 3c620004 38800100 386370d8 48219959 6000 7f83e000 7d301026 5529effe 0b09 393c0010 79291f24 7d3d4a14 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org --- v2: include the oops message in the patch description mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid num_online_nodes()); + VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); n = get_node(cachep, nodeid); BUG_ON(!n); -- 2.1.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs
(2014/12/01 13:28), Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA PowerNV Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc5-kvm+ #17 task: c13ba230 ti: c1494000 task.ti: c1494000 NIP: c0264f6c LR: c0264f5c CTR: REGS: c14979a0 TRAP: 0700 Not tainted (3.18.0-rc5-kvm+) MSR: 92021032 SF,HV,VEC,ME,IR,DR,RI CR: 28000448 XER: 2000 CFAR: c047e978 SOFTE: 0 GPR00: c0264f5c c1497c20 c1499d48 0004 GPR04: 0100 0010 0068 GPR08: 0001 082d c0cca5a8 GPR12: 48000448 cfda 01003bd44ff0 10020578 GPR16: 01003bd44ff8 01003bd45000 0001 GPR20: 0010 GPR24: c00ffe80 c0c824ec 0068 c00ffe80 GPR28: 0010 c00ffe80 0010 NIP [c0264f6c] .cache_alloc_node+0x6c/0x270 LR [c0264f5c] .cache_alloc_node+0x5c/0x270 Call Trace: [c1497c20] [c0264f5c] .cache_alloc_node+0x5c/0x270 (unreliable) [c1497cf0] [c026552c] .kmem_cache_alloc_node_trace+0xdc/0x360 [c1497dc0] [c0c824ec] .init_list+0x3c/0x128 [c1497e50] [c0c827b4] .kmem_cache_init+0x1dc/0x258 [c1497ef0] [c0c54090] .start_kernel+0x2a0/0x568 [c1497f90] [c0008c6c] start_here_common+0x20/0xa8 Instruction dump: 7c7d1b78 7c962378 4bda4e91 6000 3c620004 38800100 386370d8 48219959 6000 7f83e000 7d301026 5529effe 0b09 393c0010 79291f24 7d3d4a14 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Signed-off-by: Paul Mackerras pau...@samba.org --- Looks good to me. Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com If you need to backport it into -stable kernel, please read Documentation/stable_kernel_rules.txt. Thanks, Yasuaki Ishimatsu v2: include the oops message in the patch description mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index eb2b2ea..f34e053 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3076,7 +3076,7 @@ static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, void *obj; int x; - VM_BUG_ON(nodeid num_online_nodes()); + VM_BUG_ON(nodeid 0 || nodeid = MAX_NUMNODES); n = get_node(cachep, nodeid); BUG_ON(!n); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: ... To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. When did this break? How come we only just noticed? Also needs: Cc: sta...@vger.kernel.org cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] slab: Fix nodeid bounds check for non-contiguous node IDs
On Mon, Dec 01, 2014 at 04:02:14PM +1100, Michael Ellerman wrote: On Mon, 2014-12-01 at 15:28 +1100, Paul Mackerras wrote: The bounds check for nodeid in cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: ... To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. When did this break? How come we only just noticed? Commit 14e50c6a9bc2, which went into 3.10-rc1. You'll only notice if you have CONFIG_SLAB=y and CONFIG_DEBUG_VM=y and you're running on a machine with discontiguous node IDs. Also needs: Cc: sta...@vger.kernel.org It does. I remembered that a minute after I sent the patch. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V4] powerpc, xmon: Enable HW instruction breakpoint on POWER8
On Fri, 2014-28-11 at 04:36:42 UTC, Anshuman Khandual wrote: This patch enables support for hardware instruction breakpoint in xmon on POWER8 platform with the help of a new register called the CIABR (Completed Instruction Address Breakpoint Register). With this patch, a single hardware instruction breakpoint can be added and cleared during any active xmon debug session. The hardware based instruction breakpoint mechanism works correctly with the existing TRAP based instruction breakpoint available on xmon. There are no powerpc CPU with CPU_FTR_IABR feature any more. This patch has re-purposed all the existing IABR related code to work with CIABR register based HW instruction breakpoint. OK I think I'm happy with this, I am going to add this to the changelog though: This has one odd feature, which is that when we hit a breakpoint xmon doesn't tell us we have hit the breakpoint. This is because xmon is expecting bp-address == regs-nip. Because CIABR fires on completition regs-nip points to the instruction after the breakpoint. We could fix that, but it would then confuse other parts of the xmon code which think we need to emulate the instruction. [mpe] cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/xmon: Cleanup the breakpoint flags
Drop BP_IABR_TE, which though used, does not do anything useful. Rename
BP_IABR to BP_CIABR. Renumber the flags.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/xmon/xmon.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
This is on top of Anshuman's v4 of CIABR breakpoint support.
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 820dc135f040..dfe337238699 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -94,10 +94,9 @@ struct bpt {
};
/* Bits in bpt.enabled */
-#define BP_IABR_TE 1 /* IABR translation enabled */
-#define BP_IABR2
-#define BP_TRAP8
-#define BP_DABR0x10
+#define BP_CIABR 1
+#define BP_TRAP2
+#define BP_DABR4
#define NBPTS 256
static struct bpt bpts[NBPTS];
@@ -772,7 +771,7 @@ static void insert_bpts(void)
bp = bpts;
for (i = 0; i NBPTS; ++i, ++bp) {
- if ((bp-enabled (BP_TRAP|BP_IABR)) == 0)
+ if ((bp-enabled (BP_TRAP|BP_CIABR)) == 0)
continue;
if (mread(bp-address, bp-instr[0], 4) != 4) {
printf(Couldn't read instruction at %lx,
@@ -787,7 +786,7 @@ static void insert_bpts(void)
continue;
}
store_inst(bp-instr[0]);
- if (bp-enabled BP_IABR)
+ if (bp-enabled BP_CIABR)
continue;
if (mwrite(bp-address, bpinstr, 4) != 4) {
printf(Couldn't write instruction at %lx,
@@ -822,7 +821,7 @@ static void remove_bpts(void)
bp = bpts;
for (i = 0; i NBPTS; ++i, ++bp) {
- if ((bp-enabled (BP_TRAP|BP_IABR)) != BP_TRAP)
+ if ((bp-enabled (BP_TRAP|BP_CIABR)) != BP_TRAP)
continue;
if (mread(bp-address, instr, 4) == 4
instr == bpinstr
@@ -1217,7 +1216,7 @@ bpt_cmds(void)
break;
}
if (iabr) {
- iabr-enabled = ~(BP_IABR | BP_IABR_TE);
+ iabr-enabled = ~BP_CIABR;
iabr = NULL;
}
if (!scanhex(a))
@@ -1226,7 +1225,7 @@ bpt_cmds(void)
break;
bp = new_breakpoint(a);
if (bp != NULL) {
- bp-enabled |= BP_IABR | BP_IABR_TE;
+ bp-enabled |= BP_CIABR;
iabr = bp;
}
break;
@@ -1283,7 +1282,7 @@ bpt_cmds(void)
if (!bp-enabled)
continue;
printf(%2x %s , BP_NUM(bp),
- (bp-enabled BP_IABR)? inst: trap);
+ (bp-enabled BP_CIABR) ? inst: trap);
xmon_print_symbol(bp-address, , \n);
}
break;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] powernv: cpuidle: Redesign idle states management
On Friday 28 November 2014 05:20 AM, Paul Mackerras wrote: On Tue, Nov 25, 2014 at 04:47:58PM +0530, Shreyas B. Prabhu wrote: [snip] +2: +/* Sleep or winkle */ +li r7,1 +mfspr r8,SPRN_PIR +/* + * The last 3 bits of PIR represents the thread id of a cpu + * in power8. This will need adjusting for power7. + */ +andi. r8,r8,0x07 /* Get thread id into r8 */ +rotld r7,r7,r8 I would suggest adding another u8 field to the paca to store our thread bit, and initialize it to 1 (cpu_id % threads_per_core) early on. That will handle the POWER7 case correctly and reduce these four instructions to one. Okay. I'll make the change. + +ld r14,PACA_CORE_IDLE_STATE_PTR(r13) +lwarx_loop1: +lwarx r15,0,r14 +andcr15,r15,r7 /* Clear thread bit */ + +andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS +beq last_thread + +/* Not the last thread to goto sleep */ +stwcx. r15,0,r14 +bne-lwarx_loop1 +b common_enter + +last_thread: +LOAD_REG_ADDR(r3, pnv_need_fastsleep_workaround) +lbz r3,0(r3) +cmpwi r3,1 +bne common_enter +/* + * Last thread of the core entering sleep. Last thread needs to execute + * the hardware bug workaround code. Before that, set the lock bit to + * avoid the race of other threads waking up and undoing workaround + * before workaround is applied. + */ +ori r15,r15,PNV_CORE_IDLE_LOCK_BIT +stwcx. r15,0,r14 +bne-lwarx_loop1 + +/* Fast sleep workaround */ +li r3,1 +li r4,1 +li r0,OPAL_CONFIG_CPU_IDLE_STATE +bl opal_call_realmode + +/* Clear Lock bit */ +andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS +stw r15,0(r14) In this case we know the result of the andi. will be 0, so this could be just li r0,0; stw r0,0(r14). Yes. I'll make the change. + +common_enter: /* common code for all the threads entering sleep */ +IDLE_STATE_ENTER_SEQ(PPC_SLEEP) _GLOBAL(power7_idle) /* Now check if user or arch enabled NAP mode */ @@ -141,49 +191,16 @@ _GLOBAL(power7_idle) _GLOBAL(power7_nap) mr r4,r3 -li r3,0 +li r3,PNV_THREAD_NAP b power7_powersave_common /* No return */ _GLOBAL(power7_sleep) -li r3,1 +li r3,PNV_THREAD_SLEEP li r4,1 b power7_powersave_common /* No return */ -/* - * Make opal call in realmode. This is a generic function to be called - * from realmode from reset vector. It handles endianess. - * - * r13 - paca pointer - * r1 - stack pointer - * r3 - opal token - */ -opal_call_realmode: -mflrr12 -std r12,_LINK(r1) -ld r2,PACATOC(r13) -/* Set opal return address */ -LOAD_REG_ADDR(r0,return_from_opal_call) -mtlrr0 -/* Handle endian-ness */ -li r0,MSR_LE -mfmsr r12 -andcr12,r12,r0 -mtspr SPRN_HSRR1,r12 -mr r0,r3 /* Move opal token to r0 */ -LOAD_REG_ADDR(r11,opal) -ld r12,8(r11) -ld r2,0(r11) -mtspr SPRN_HSRR0,r12 -hrfid - -return_from_opal_call: -FIXUP_ENDIAN -ld r0,_LINK(r1) -mtlrr0 -blr - #define CHECK_HMI_INTERRUPT \ mfspr r0,SPRN_SRR1; \ BEGIN_FTR_SECTION_NESTED(66); \ @@ -196,10 +213,8 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66);\ /* Invoke opal call to handle hmi */\ ld r2,PACATOC(r13);\ ld r1,PACAR1(r13); \ -std r3,ORIG_GPR3(r1); /* Save original r3 */ \ -li r3,OPAL_HANDLE_HMI; /* Pass opal token argument*/ \ +li r0,OPAL_HANDLE_HMI; /* Pass opal token argument*/ \ bl opal_call_realmode; \ -ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \ 20: nop; @@ -210,12 +225,91 @@ _GLOBAL(power7_wakeup_tb_loss) BEGIN_FTR_SECTION CHECK_HMI_INTERRUPT END_FTR_SECTION_IFSET(CPU_FTR_HVMODE) + +li r7,1 +mfspr r8,SPRN_PIR +/* + * The last 3 bits of PIR represents the thread id of a cpu + * in power8. This will need adjusting for power7. + */ +andi. r8,r8,0x07 /* Get thread id into r8 */ +rotld r7,r7,r8 +/* r7 now has 'thread_id'th bit set */ + +ld r14,PACA_CORE_IDLE_STATE_PTR(r13) +lwarx_loop2: +lwarx r15,0,r14 +andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT +/* + * Lock bit is set in one of the 2 cases- + * a. In the sleep/winkle enter path,
Re: [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
Hi, On Mon, Dec 01, 2014 at 11:50:51AM +0900, Jiada Wang wrote: irq_dispose_mapping() in turns calls unregister_irq_proc(), which will remove irq proc entry, if IRQ is not freed before calling of irq_dispose_mapping(), then it will cause kernel warning. By free IRQ before irq_dispose_mapping(), this patch fix the following kernel warning found when remove of fsl_ssi driver: [ 31.515336] [ cut here ] [ 31.520091] WARNING: CPU: 2 PID: 434 at fs/proc/generic.c:521 remove_proc_entry+0x14c/0x16c() [ 31.528708] remove_proc_entry: removing non-empty directory 'irq/79', leaking at least '202c000.ss' [ 31.537911] Modules linked in: snd_soc_wm8962 snd_soc_imx_wm8962 snd_soc_fsl_ssi(-) evbug [ 31.546249] CPU: 2 PID: 434 Comm: rmmod Not tainted 3.18.0-rc6-00028-g3314bf6-dirty #1 [ 31.554235] Backtrace: [ 31.556816] [80011ea8] (dump_backtrace) from [80012044] (show_stack+0x18/0x1c) [ 31.564416] r6:80142c88 r5: r4: r3: [ 31.570267] [8001202c] (show_stack) from [806980ec] (dump_stack+0x88/0xa4) [ 31.577588] [80698064] (dump_stack) from [80029d78] (warn_slowpath_common+0x70/0x94) [ 31.585711] r5:0009 r4:bb61fd90 [ 31.589423] [80029d08] (warn_slowpath_common) from [80029e40] (warn_slowpath_fmt+0x38/0x40) [ 31.598187] r8:bb61fdfe r7:be05d76d r6:be05d9a8 r5:0002 r4:be05d700 [ 31.605054] [80029e0c] (warn_slowpath_fmt) from [80142c88] (remove_proc_entry+0x14c/0x16c) [ 31.613709] r3:806a79c0 r2:808229a0 [ 31.617371] [80142b3c] (remove_proc_entry) from [80070380] (unregister_irq_proc+0x94/0xb8) [ 31.625989] r10: r8:8000ede4 r7:80955f2c r6:004f r5:8118e738 r4:be00af00 [ 31.633952] [800702ec] (unregister_irq_proc) from [80069dac] (free_desc+0x2c/0x64) [ 31.641898] r6:004f r5:80955f38 r4:be00af00 [ 31.646604] [80069d80] (free_desc) from [80069e68] (irq_free_descs+0x4c/0x8c) [ 31.654092] r7:0081 r6:0001 r5:004f r4:0001 [ 31.659863] [80069e1c] (irq_free_descs) from [8006fc3c] (irq_dispose_mapping+0x40/0x5c) [ 31.668247] r6:be17b844 r5:be17b800 r4:004f r3:802c5ec0 [ 31.673998] [8006fbfc] (irq_dispose_mapping) from [7f004ea4] (fsl_ssi_remove+0x58/0x70 [snd_so) [ 31.683948] r4:bb5bba10 r3:0001 [ 31.687618] [7f004e4c] (fsl_ssi_remove [snd_soc_fsl_ssi]) from [803720a0] (platform_drv_remove) [ 31.697564] r5:7f0064f8 r4:be17b810 [ 31.701195] [80372080] (platform_drv_remove) from [80370494] (__device_release_driver+0x78/0xc) [ 31.710361] r5:7f0064f8 r4:be17b810 [ 31.713987] [8037041c] (__device_release_driver) from [80370d20] (driver_detach+0xbc/0xc0) [ 31.722631] r5:7f0064f8 r4:be17b810 [ 31.726259] [80370c64] (driver_detach) from [80370304] (bus_remove_driver+0x54/0x98) [ 31.734382] r6:0800 r5: r4:7f0064f8 r3:bb67f500 [ 31.740149] [803702b0] (bus_remove_driver) from [80371398] (driver_unregister+0x30/0x50) [ 31.748617] r4:7f0064f8 r3:bd9f7080 [ 31.752245] [80371368] (driver_unregister) from [80371f3c] (platform_driver_unregister+0x14/0x) [ 31.761498] r4:7f00655c r3:7f005a70 [ 31.765130] [80371f28] (platform_driver_unregister) from [7f005a84] (fsl_ssi_driver_exit+0x14/) [ 31.776147] [7f005a70] (fsl_ssi_driver_exit [snd_soc_fsl_ssi]) from [8008ed80] (SyS_delete_mod) [ 31.786553] [8008ec64] (SyS_delete_module) from [8000ec20] (ret_fast_syscall+0x0/0x48) [ 31.794824] r6:00c46d18 r5:0800 r4:00c46d18 [ 31.799530] ---[ end trace 954e8a3a15379e52 ]--- Moreover replace devm_request_irq() with request_irq() since there is no need to use it as now driver always frees IRQ manually. devm_request_irq() is used by other drivers too, this should not be a problem. Looking at the code it seems that irq_dispose_mapping may not be necessary with devm_request_irq(). So I think it would be better to remove irq_dispose_mapping() instead. Best Regards, Markus Pargmann -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
