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

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2013-09-03 at 10:09 +0200, Dominik Vogt wrote:
> 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.

Which would be just a performance problem for glibc, though, as I argued
in a reply to your other email.

> 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.

To me, the critical distinction is whether misinterpretation of an abort
code can affect correctness, or can significantly mess up performance
(ie, more than what we currently can have anyway due to the very simple
adaptation mechanism).