Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On 12/11/2015 06:04 AM, Will Deacon wrote: I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, as opposed to "compare and swap". In which case, it does look like there's a bug here because there is nothing to order the initialisation of the node fields with publishing of the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On 12/11/2015 06:04 AM, Will Deacon wrote: I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, as opposed to "compare and swap". In which case, it does look like there's a bug here because there is nothing to order the initialisation of the node fields with publishing of the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Mon, Dec 14, 2015 at 09:28:55PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:35:40PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > > On Fri, Dec 11, 2015 at

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:35:40PM -0800, Paul E. McKenney wrote: > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > > > While we're there,

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Mon, Dec 14, 2015 at 09:28:55PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:35:40PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > > On Fri, Dec 11, 2015 at

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:35:40PM -0800, Paul E. McKenney wrote: > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > > > While we're there,

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > > documented too. > >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 06:11:28PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:06:49PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > > On Fri, Dec 11, 2015 at

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:06:49PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > > > While we're there, the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, 11 Dec 2015, Will Deacon wrote: I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, as opposed to "compare and swap". In which case, it does look like there's a bug here because there is nothing to order the initialisation of the node fields with publishing of the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > > documented too. > >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > documented too. > > > > I _think_ we need ACQUIRE semantics there because we want to

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 12:18:00PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > > > I think Andrew meant the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 12:18:00PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > > > as opposed to "compare

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > > as opposed to "compare and swap". In which case, it does look like > > there's a bug here

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > as opposed to "compare and swap". In which case, it does look like > there's a bug here because there is nothing to order the initialisation > of the node fields

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

Hi all, On Fri, Dec 11, 2015 at 09:41:33AM +0100, Peter Zijlstra wrote: > On Thu, Dec 10, 2015 at 08:51:34PM -0800, Andrew Pinski wrote: > > > So looking further I think I understand what is going wrong and why > > c55a6ffa6285e29f874ed403979472631ec70bff is incorrect. > > The osq_wait_next()

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 08:51:34PM -0800, Andrew Pinski wrote: > So looking further I think I understand what is going wrong and why > c55a6ffa6285e29f874ed403979472631ec70bff is incorrect. The osq_wait_next() call in osq_lock() is when we fail the lock. This is effectively trylock() semantics

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

Hi all, On Fri, Dec 11, 2015 at 09:41:33AM +0100, Peter Zijlstra wrote: > On Thu, Dec 10, 2015 at 08:51:34PM -0800, Andrew Pinski wrote: > > > So looking further I think I understand what is going wrong and why > > c55a6ffa6285e29f874ed403979472631ec70bff is incorrect. > > The osq_wait_next()

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > > as opposed to "compare and swap". In which case, it does look like > > there's a bug here

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > as opposed to "compare and swap". In which case, it does look like > there's a bug here because there is nothing to order the initialisation > of the node fields

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 12:18:00PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > > I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, > > > as opposed to "compare

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > documented too. > > > > I _think_ we need ACQUIRE semantics there because we want to

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > > documented too. > >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, 11 Dec 2015, Will Deacon wrote: I think Andrew meant the atomic_xchg_acquire at the start of osq_lock, as opposed to "compare and swap". In which case, it does look like there's a bug here because there is nothing to order the initialisation of the node fields with publishing of the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 12:18:00PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:13:19PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 12:04:19PM +, Will Deacon wrote: > > > > I think Andrew meant the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:06:49PM +, Will Deacon wrote: > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > > > While we're there, the

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 01:26:47PM +0100, Peter Zijlstra wrote: > > > > While we're there, the acquire in osq_wait_next() seems somewhat ill > > > documented too. > >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 08:51:34PM -0800, Andrew Pinski wrote: > So looking further I think I understand what is going wrong and why > c55a6ffa6285e29f874ed403979472631ec70bff is incorrect. The osq_wait_next() call in osq_lock() is when we fail the lock. This is effectively trylock() semantics

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Fri, Dec 11, 2015 at 06:11:28PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:06:49PM +, Will Deacon wrote: > > On Fri, Dec 11, 2015 at 02:48:03PM +0100, Peter Zijlstra wrote: > > > On Fri, Dec 11, 2015 at 01:33:14PM +, Will Deacon wrote: > > > > On Fri, Dec 11, 2015 at

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 07:29:34PM -0800, Andrew Pinski wrote: > On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: > > > > Hi, > > > > We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which > > is an arm64 implementation. > > I get a slightly different OOPs and reverting >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 7:29 PM, Andrew Pinski wrote: > On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: >> >> Hi, >> >> We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which is >> an arm64 implementation. > > I get a slightly different OOPs and reverting >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: > > Hi, > > We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which is > an arm64 implementation. I get a slightly different OOPs and reverting c55a6ffa6285e29f874ed403979472631ec70bff I was able to boot. What I saw with

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: > > Hi, > > We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which is > an arm64 implementation. I get a slightly different OOPs and reverting c55a6ffa6285e29f874ed403979472631ec70bff I was able to boot. What I saw with

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 07:29:34PM -0800, Andrew Pinski wrote: > On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: > > > > Hi, > > > > We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which > > is an arm64 implementation. > > I get a slightly different OOPs and reverting >

Re: FW: Commit 81a43adae3b9 (locking/mutex: Use acquire/release semantics) causing failures on arm64 (ThunderX)

On Thu, Dec 10, 2015 at 7:29 PM, Andrew Pinski wrote: > On Thu, Dec 10, 2015 at 11:44 AM, David Danny wrote: >> >> Hi, >> >> We are getting soft lockup OOPs on Cavium CN88XX (A.K.A. ThunderX), which is >> an arm64 implementation. > > I get a slightly different OOPs and