Lock elision problems in glibc-2.18

[Dominik Vogt]

On Mon, Sep 16, 2013 at 05:06:26PM +0200, Torvald Riegel wrote:
> On Mon, 2013-09-16 at 12:25 +0200, Dominik Vogt wrote:
> > On Mon, Sep 16, 2013 at 10:58:06AM +0200, Torvald Riegel wrote:
> > > On Fri, 2013-09-13 at 23:23 -0700, Andi Kleen wrote:
> > > > Torvald Riegel <triegel@redhat.com> writes:
> > > > 
> > > > >  We need to do this, and if the app
> > > > > misinterprets and *always* keeps retrying, it will hang.
> > > > 
> > > > The app is broken then. Retrying forever is simply not allowed.
> > > > I don't think it makes sense to complicate glibc for this.

Anyway, even if the application does not retry forever, this is no
guarantee that the glibc abort handler is ever called.  The
fallback code might use other mechanisms but pthread_mutex_lock
for protection and thus the mutexes that aborted might not be used
at all.  Thus, the glibc code must not rely on its abort handlers
ever being called.

I am very reluctant to claim all sorts of scenarios to be broken
or impossible with the knowledge we have at the moment.  The fact
that glibc interfaces are backed by Posix does not make it immune
to bugs.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany