Re: [PATCH 5/6] Do not use explicit abort code definitions.

[Dominik Vogt <vogt at linux dot vnet dot ibm dot com>]

On Mon, Sep 02, 2013 at 02:02:38PM -0700, Andi Kleen wrote:
> Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
> 
> > Using explicit abort code definitions is problematic because they are thrown at
> > the creator of the outermost transaction who may misinterpret the user
> > specified abort code because he does not know where it comes from.
> >
> > The lock elision implementation should refrain from using explicit abort code
> > definitions and rather only interpret the flags of the abort code (as should
> > other pieces of software that have abort handlers).
> 
> 
> Nack nack.
> 
> This is used for profiling.

Yes, but that is not the whole story.  The abort codes are also
used for program flow control (at least the ..._BUSY code) in my
eyes this is a no go because there's no guarantee that that code
was really generated in glibc.  There could be a nested
transaction in a third party library that aborts one of its own
transactions with that code, and glibc, if it opened the outermost
transaction, would misinterpret this third party abort code as one
that was generated by itself and change current and future program
flow because of that.

I understand that profiling is an important issue.  In my eyes it
is allright to _set_ your own abort codes for debugging purposes,
but not to determine control flow depending on abort codes.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany