[PATCH 4.1 003/123] powerpc/powernv: Fix race in updating core_idle_state
4.1-stable review patch. If anyone has any objections, please let me know. -- From: "Shreyas B. Prabhu" commit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream. core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -150,6 +166,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -294,7 +314,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -319,15 +339,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4.1 003/123] powerpc/powernv: Fix race in updating core_idle_state
4.1-stable review patch. If anyone has any objections, please let me know. -- From: Shreyas B. Prabhu shre...@linux.vnet.ibm.com commit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream. core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Signed-off-by: Michael Ellerman m...@ellerman.id.au Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -150,6 +166,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -294,7 +314,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -319,15 +339,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.19.y-ckt 024/107] powerpc/powernv: Fix race in updating core_idle_state
3.19.8-ckt5 -stable review patch. If anyone has any objections, please let me know. -- From: "Shreyas B. Prabhu" commit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream. core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Signed-off-by: Michael Ellerman Signed-off-by: Kamal Mostafa --- arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index 401d8d0..7bc5750 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -149,6 +165,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -293,7 +313,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -318,15 +338,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.19.y-ckt 024/107] powerpc/powernv: Fix race in updating core_idle_state
3.19.8-ckt5 -stable review patch. If anyone has any objections, please let me know. -- From: Shreyas B. Prabhu shre...@linux.vnet.ibm.com commit b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 upstream. core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Signed-off-by: Michael Ellerman m...@ellerman.id.au Signed-off-by: Kamal Mostafa ka...@canonical.com --- arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index 401d8d0..7bc5750 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -149,6 +165,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -293,7 +313,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -318,15 +338,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On Thu, 2015-07-09 at 14:41 +1000, Daniel Axtens wrote: > > I recommend creating an alias or script that does: > > > > $ git log --pretty=fixes -n 1 $commit | xclip > > > > FWIW, having finally got around to doing this, I found I first needed > the following snippet in ~/.gitconfig from > https://www.kernel.org/doc/Documentation/SubmittingPatches > > > [core] > abbrev = 12 > [pretty] > fixes = Fixes: %h (\"%s\") > > Otherwise git doesn't know what the pretty format is. Oh right, yeah. Doesn't everyone have my dotfiles!? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On 07/09/2015 10:11 AM, Daniel Axtens wrote: >> I recommend creating an alias or script that does: >> >> $ git log --pretty=fixes -n 1 $commit | xclip >> > > FWIW, having finally got around to doing this, I found I first needed > the following snippet in ~/.gitconfig from > https://www.kernel.org/doc/Documentation/SubmittingPatches > > > [core] > abbrev = 12 > [pretty] > fixes = Fixes: %h (\"%s\") > > Otherwise git doesn't know what the pretty format is. > Right, thanks for the pointer! Thanks, Shreyas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On Thu, 2015-07-09 at 14:41 +1000, Daniel Axtens wrote: I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip FWIW, having finally got around to doing this, I found I first needed the following snippet in ~/.gitconfig from https://www.kernel.org/doc/Documentation/SubmittingPatches [core] abbrev = 12 [pretty] fixes = Fixes: %h (\%s\) Otherwise git doesn't know what the pretty format is. Oh right, yeah. Doesn't everyone have my dotfiles!? cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On 07/09/2015 10:11 AM, Daniel Axtens wrote: I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip FWIW, having finally got around to doing this, I found I first needed the following snippet in ~/.gitconfig from https://www.kernel.org/doc/Documentation/SubmittingPatches [core] abbrev = 12 [pretty] fixes = Fixes: %h (\%s\) Otherwise git doesn't know what the pretty format is. Right, thanks for the pointer! Thanks, Shreyas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
> I recommend creating an alias or script that does: > > $ git log --pretty=fixes -n 1 $commit | xclip > FWIW, having finally got around to doing this, I found I first needed the following snippet in ~/.gitconfig from https://www.kernel.org/doc/Documentation/SubmittingPatches [core] abbrev = 12 [pretty] fixes = Fixes: %h (\"%s\") Otherwise git doesn't know what the pretty format is. -- Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip FWIW, having finally got around to doing this, I found I first needed the following snippet in ~/.gitconfig from https://www.kernel.org/doc/Documentation/SubmittingPatches [core] abbrev = 12 [pretty] fixes = Fixes: %h (\%s\) Otherwise git doesn't know what the pretty format is. -- Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: [v2] powerpc/powernv: Fix race in updating core_idle_state
On Mon, 2015-06-07 at 20:09:23 UTC, "Shreyas B. Prabhu" wrote: > core_idle_state is maintained for each core. It uses 0-7 bits to track > whether a thread in the core has entered fastsleep or winkle. 8th bit is > used as a lock bit. ... > Signed-off-by: Shreyas B. Prabhu > Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline > cpus' Applied to powerpc fixes, thanks. https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixes=b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2] powerpc/powernv: Fix race in updating core_idle_state
On Mon, 2015-06-07 at 20:09:23 UTC, Shreyas B. Prabhu wrote: core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. ... Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' Applied to powerpc fixes, thanks. https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixesid=b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On 07/07/2015 05:52 AM, Michael Ellerman wrote: > On Tue, 2015-07-07 at 01:39 +0530, Shreyas B. Prabhu wrote: >> Signed-off-by: Shreyas B. Prabhu >> Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline >> cpus' > > The sha is wrong, it should be 77b54e9f213f. > Argh! Sorry > Also please don't wrap the description. > > I recommend creating an alias or script that does: > > $ git log --pretty=fixes -n 1 $commit | xclip > Will use this from next time. > > I've fixed it up, no need to resend. > Thanks! --Shreyas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On Tue, 2015-07-07 at 01:39 +0530, Shreyas B. Prabhu wrote: > core_idle_state is maintained for each core. It uses 0-7 bits to track > whether a thread in the core has entered fastsleep or winkle. 8th bit is > used as a lock bit. ... > This patch fixes the above race by looping on the lock bit even while > entering the idle states. > > Signed-off-by: Shreyas B. Prabhu > Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline > cpus' The sha is wrong, it should be 77b54e9f213f. Also please don't wrap the description. I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip I've fixed it up, no need to resend. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' --- This needs to go into stable 3.19+ Changes in v2: - - Based on suggestion from Micheal, core_idle_lock_held changed to a function call so that the same block can be called in entry and exit path. - More detail on how this bug manifests added to commit message. arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index ccde8f0..4d04315 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -150,6 +166,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -294,7 +314,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -319,15 +339,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. In such cases when the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' --- This needs to go into stable 3.19+ Changes in v2: - - Based on suggestion from Micheal, core_idle_lock_held changed to a function call so that the same block can be called in entry and exit path. - More detail on how this bug manifests added to commit message. arch/powerpc/kernel/idle_power7.S | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index ccde8f0..4d04315 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -52,6 +52,22 @@ .text /* + * Used by threads when the lock bit of core_idle_state is set. + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state + */ + +core_idle_lock_held: + HMT_LOW +3: lwz r15,0(r14) + andi. r15,r15,PNV_CORE_IDLE_LOCK_BIT + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 + blr + +/* * Pass requested state in r3: * r3 - PNV_THREAD_NAP/SLEEP/WINKLE * @@ -150,6 +166,10 @@ power7_enter_nap_mode: ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bnelcore_idle_lock_held + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS @@ -294,7 +314,7 @@ lwarx_loop2: * workaround undo code or resyncing timebase or restoring context * In either case loop until the lock bit is cleared. */ - bne core_idle_lock_held + bnelcore_idle_lock_held cmpwi cr2,r15,0 lbz r4,PACA_SUBCORE_SIBLING_MASK(r13) @@ -319,15 +339,6 @@ lwarx_loop2: isync b common_exit -core_idle_lock_held: - HMT_LOW -core_idle_lock_loop: - lwz r15,0(14) - andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT - bne core_idle_lock_loop - HMT_MEDIUM - b lwarx_loop2 - first_thread_in_subcore: /* First thread in subcore to wakeup */ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On Tue, 2015-07-07 at 01:39 +0530, Shreyas B. Prabhu wrote: core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. ... This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' The sha is wrong, it should be 77b54e9f213f. Also please don't wrap the description. I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip I've fixed it up, no need to resend. cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] powerpc/powernv: Fix race in updating core_idle_state
On 07/07/2015 05:52 AM, Michael Ellerman wrote: On Tue, 2015-07-07 at 01:39 +0530, Shreyas B. Prabhu wrote: Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline cpus' The sha is wrong, it should be 77b54e9f213f. Argh! Sorry Also please don't wrap the description. I recommend creating an alias or script that does: $ git log --pretty=fixes -n 1 $commit | xclip Will use this from next time. I've fixed it up, no need to resend. Thanks! --Shreyas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
> > What are the symptoms of this bug? > In the cases where we hit this race and the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. We suspect this is causing soft lockups with call stacks similar to this- [126529.208714] NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [opal_errd:7722] [126529.208849] CPU: 8 PID: 7722 Comm: opal_errd [126529.208853] task: c0bf67803a80 ti: c0bf6788c000 task.ti: c0bf6788c000 [126529.208856] NIP: c015a180 LR: c015a0d0 CTR: c001ed70 [126529.208859] REGS: c0bf6788faa0 TRAP: 0901 Not tainted (3.18.13-336.el7_1.pkvm3_1_0.2000.1.ppc64le) [126529.208860] MSR: 90009033 CR: 24004824 XER: 2000 [126529.208871] CFAR: c015a194 SOFTE: 1 GPR00: c02db9e8 c0bf6788fd20 c12b1800 3af5b88f569e GPR04: 00d3dbb8 3af5c236ca0b 0001ee28 GPR08: 3b9ac9ff 5bfc723fba82c8f9 c06f2b88 c09908c8 GPR12: c001ed70 c7da4c00 [126529.208896] NIP [c015a180] ktime_get_ts64+0x130/0x1f0 [126529.208899] LR [c015a0d0] ktime_get_ts64+0x80/0x1f0 [126529.208902] Call Trace: [126529.208909] [c0bf6788fd20] [c019c0e4] __audit_syscall_exit+0x214/0x2e0 (unreliable) [126529.208916] [c0bf6788fda0] [c02db9e8] poll_select_set_timeout+0x98/0xe0 [126529.208919] [c0bf6788fde0] [c02dcf7c] SyS_poll+0x8c/0x160 [126529.208925] [c0bf6788fe30] [c0009358] syscall_exit+0x0/0x98 [126529.208927] Instruction dump: [126529.208930] 7d29ea14 6108c9ff 3940 7fa94040 409d0038 481c 6000 6000 [126529.208936] 6000 6000 6000 6042 <3d29c465> 394a0001 39293600 794a0020 > I assume they're not good. In which case this should go to stable, shouldn't > it? If so which versions? > Yes this should go into stable. 3.19+ > And which commit introduced the bug? > 77b54e9f213f76a powernv/powerpc: Add winkle support for offline cpus Thanks, Shreyas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
On Wed, 2015-01-07 at 06:34:10 UTC, "Shreyas B. Prabhu" wrote: > core_idle_state is maintained for each core. It uses 0-7 bits to track > whether a thread in the core has entered fastsleep or winkle. 8th bit is > used as a lock bit. > The lock bit is set in these 2 scenarios- > - The thread is first in subcore to wakeup from sleep/winkle. > - If its the last thread in the core about to enter sleep/winkle > > While the lock bit is set, if any other thread in the core wakes up, it > loops until the lock bit is cleared before proceeding in the wakeup > path. This helps prevent race conditions w.r.t fastsleep workaround and > prevents threads from switching to process context before core/subcore > resources are restored. > > But, in the path to sleep/winkle entry, we currently don't check for > lock-bit. This exposes us to following race when running with subcore > on- > > First thread in the subcorea Another thread in the same > waking up core entering sleep/winkle > > lwarx r15,0,r14 > ori r15,r15,PNV_CORE_IDLE_LOCK_BIT > stwcx. r15,0,r14 > [Code to restore subcore state] > > lwarx r15,0,r14 > [clear thread bit] > stwcx. r15,0,r14 > > andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS > stw r15,0(r14) > > Here, after the thread entering sleep clears its thread bit in > core_idle_state, the value is overwritten by the thread waking up. > This patch fixes the above race by looping on the lock bit even while > entering the idle states. What are the symptoms of this bug? I assume they're not good. In which case this should go to stable, shouldn't it? If so which versions? And which commit introduced the bug? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
What are the symptoms of this bug? In the cases where we hit this race and the core enters fastsleep, code mistakes an idle thread as running. Because of this, the first thread waking up from fastsleep which is supposed to resync timebase skips it. So we can end up having a core with stale timebase value. We suspect this is causing soft lockups with call stacks similar to this- [126529.208714] NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [opal_errd:7722] [126529.208849] CPU: 8 PID: 7722 Comm: opal_errd [126529.208853] task: c0bf67803a80 ti: c0bf6788c000 task.ti: c0bf6788c000 [126529.208856] NIP: c015a180 LR: c015a0d0 CTR: c001ed70 [126529.208859] REGS: c0bf6788faa0 TRAP: 0901 Not tainted (3.18.13-336.el7_1.pkvm3_1_0.2000.1.ppc64le) [126529.208860] MSR: 90009033 SF,HV,EE,ME,IR,DR,RI,LE CR: 24004824 XER: 2000 [126529.208871] CFAR: c015a194 SOFTE: 1 GPR00: c02db9e8 c0bf6788fd20 c12b1800 3af5b88f569e GPR04: 00d3dbb8 3af5c236ca0b 0001ee28 GPR08: 3b9ac9ff 5bfc723fba82c8f9 c06f2b88 c09908c8 GPR12: c001ed70 c7da4c00 [126529.208896] NIP [c015a180] ktime_get_ts64+0x130/0x1f0 [126529.208899] LR [c015a0d0] ktime_get_ts64+0x80/0x1f0 [126529.208902] Call Trace: [126529.208909] [c0bf6788fd20] [c019c0e4] __audit_syscall_exit+0x214/0x2e0 (unreliable) [126529.208916] [c0bf6788fda0] [c02db9e8] poll_select_set_timeout+0x98/0xe0 [126529.208919] [c0bf6788fde0] [c02dcf7c] SyS_poll+0x8c/0x160 [126529.208925] [c0bf6788fe30] [c0009358] syscall_exit+0x0/0x98 [126529.208927] Instruction dump: [126529.208930] 7d29ea14 6108c9ff 3940 7fa94040 409d0038 481c 6000 6000 [126529.208936] 6000 6000 6000 6042 3d29c465 394a0001 39293600 794a0020 I assume they're not good. In which case this should go to stable, shouldn't it? If so which versions? Yes this should go into stable. 3.19+ And which commit introduced the bug? 77b54e9f213f76a powernv/powerpc: Add winkle support for offline cpus Thanks, Shreyas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/powernv: Fix race in updating core_idle_state
On Wed, 2015-01-07 at 06:34:10 UTC, Shreyas B. Prabhu wrote: core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcorea Another thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. This patch fixes the above race by looping on the lock bit even while entering the idle states. What are the symptoms of this bug? I assume they're not good. In which case this should go to stable, shouldn't it? If so which versions? And which commit introduced the bug? cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/powernv: Fix race in updating core_idle_state
core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu --- arch/powerpc/kernel/idle_power7.S | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index ccde8f0..48c7d4f 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -144,12 +144,26 @@ power7_enter_nap_mode: bge cr3,2f IDLE_STATE_ENTER_SEQ(PPC_NAP) /* No return */ + +core_idle_lock_held_entry: + HMT_LOW +core_idle_lock_loop_entry: + lwz r15,0(r14) + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_loop_entry + HMT_MEDIUM + b lwarx_loop1 + 2: /* Sleep or winkle */ lbz r7,PACA_THREAD_MASK(r13) ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_held_entry + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/powernv: Fix race in updating core_idle_state
core_idle_state is maintained for each core. It uses 0-7 bits to track whether a thread in the core has entered fastsleep or winkle. 8th bit is used as a lock bit. The lock bit is set in these 2 scenarios- - The thread is first in subcore to wakeup from sleep/winkle. - If its the last thread in the core about to enter sleep/winkle While the lock bit is set, if any other thread in the core wakes up, it loops until the lock bit is cleared before proceeding in the wakeup path. This helps prevent race conditions w.r.t fastsleep workaround and prevents threads from switching to process context before core/subcore resources are restored. But, in the path to sleep/winkle entry, we currently don't check for lock-bit. This exposes us to following race when running with subcore on- First thread in the subcoreaAnother thread in the same waking up core entering sleep/winkle lwarx r15,0,r14 ori r15,r15,PNV_CORE_IDLE_LOCK_BIT stwcx. r15,0,r14 [Code to restore subcore state] lwarx r15,0,r14 [clear thread bit] stwcx. r15,0,r14 andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS stw r15,0(r14) Here, after the thread entering sleep clears its thread bit in core_idle_state, the value is overwritten by the thread waking up. This patch fixes the above race by looping on the lock bit even while entering the idle states. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- arch/powerpc/kernel/idle_power7.S | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index ccde8f0..48c7d4f 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -144,12 +144,26 @@ power7_enter_nap_mode: bge cr3,2f IDLE_STATE_ENTER_SEQ(PPC_NAP) /* No return */ + +core_idle_lock_held_entry: + HMT_LOW +core_idle_lock_loop_entry: + lwz r15,0(r14) + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_loop_entry + HMT_MEDIUM + b lwarx_loop1 + 2: /* Sleep or winkle */ lbz r7,PACA_THREAD_MASK(r13) ld r14,PACA_CORE_IDLE_STATE_PTR(r13) lwarx_loop1: lwarx r15,0,r14 + + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT + bne core_idle_lock_held_entry + andcr15,r15,r7 /* Clear thread bit */ andi. r15,r15,PNV_CORE_IDLE_THREAD_BITS -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
