Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 30 Jan 2019 17:44:42 -0800
From:   "Paul E. McKenney" <paulmck@linux.ibm.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Sebastian Sewior <bigeasy@linutronix.de>,
        Heiko Carstens <heiko.carstens@de.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        LKML <linux-kernel@vger.kernel.org>, linux-s390@vger.kernel.org,
        Stefan Liebler <stli@linux.ibm.com>
Subject: Re: WARN_ON_ONCE(!new_owner) within wake_futex_pi() triggerede
Reply-To: paulmck@linux.ibm.com
References: <alpine.DEB.2.21.1901301303320.5537@nanos.tec.linutronix.de>
 <20190130125955.GD5299@osiris>
 <20190130132420.spwrq2d4oxeydk5s@linutronix.de>
 <alpine.DEB.2.21.1901301428390.5537@nanos.tec.linutronix.de>
 <alpine.DEB.2.21.1901301517220.1950@nanos.tec.linutronix.de>
 <alpine.DEB.2.21.1901301853290.1622@nanos.tec.linutronix.de>
 <20190130210733.mg6aascw2gzl3oqz@linutronix.de>
 <alpine.DEB.2.21.1901302314590.8200@nanos.tec.linutronix.de>
 <20190130233557.GA4240@linux.ibm.com>
 <alpine.DEB.2.21.1901310049440.8200@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1901310049440.8200@nanos.tec.linutronix.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20190131014442.GB4240@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 31, 2019 at 12:55:18AM +0100, Thomas Gleixner wrote:
> On Wed, 30 Jan 2019, Paul E. McKenney wrote:
> > On Thu, Jan 31, 2019 at 12:13:51AM +0100, Thomas Gleixner wrote:
> > > I might be wrong as usual, but this would definitely explain the fail very
> > > well.
> > 
> > On recent versions of GCC, the fix would be to put this between the two
> > stores that need ordering:
> > 
> > 	__atomic_thread_fence(__ATOMIC_RELEASE);
> > 
> > I must defer to Heiko on whether s390 GCC might tear the stores.  My
> > guess is "probably not".  ;-)
> 
> So I just checked the latest glibc code. It has:
> 
>             /* We must not enqueue the mutex before we have acquired it.
>                Also see comments at ENQUEUE_MUTEX.  */
>             __asm ("" ::: "memory");
>             ENQUEUE_MUTEX_PI (mutex);
>             /* We need to clear op_pending after we enqueue the mutex.  */
>             __asm ("" ::: "memory");
>             THREAD_SETMEM (THREAD_SELF, robust_head.list_op_pending, NULL);
> 
> 8f9450a0b7a9 ("Add compiler barriers around modifications of the robust mutex list.")
> 
> in the glibc repository, There since Dec 24 2016 ...
> 
> So the question is whether this is sufficient. That ordering only only
> matters vs. the thread itself and not for others.

Ah, in that case you can use __atomic_signal_fence(__ATOMIC_RELEASE)
instead of the __atomic_thread_fence(__ATOMIC_RELEASE).

The __atomic_thread_fence(__ATOMIC_RELEASE) provides ordering between
threads, but __atomic_signal_fence(__ATOMIC_RELEASE) only does so
within a thread.

							Thanx, Paul