Re: [PATCH] Make some asan builtins tm_pure (PR sanitizer/55508)

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2012-12-14 at 13:44 +0400, Dmitry Vyukov wrote:
> On Thu, Dec 13, 2012 at 1:02 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> >> > Various TM tests ICE when built with -fgnu-tm -fsanitizer=address.
> >> > The problem is that asan.c pass adds calls to builtins that weren't there
> >> > before and TM is upset about it.  The __asan_report* are all like
> >> > abort, in correctly written program they shouldn't have a user visible
> >> > effect, in bad program they will terminate the process, but in any case
> >> > it doesn't matter how many times they are retried as part of a transaction,
> >> > there is no state to roll back on transaction cancellation.
> >> > __asan_handle_no_return, while not being noreturn, just marks the stack as
> >> > unprotected, so again in correctly written application no effect, in bad app
> >> > might result in some issues being undetected, but still, it can be done many
> >> > times and isn't irreversible.
> >>
> >> I was only loosely following tm-languages discussions. Does gcc tm
> >> model guarantees strong consistency for all memory accesses? I mean
> >> there are tm implementations that allow transient inconsistencies,
> >
> > Will leave this to Torvald.
> >
> >> than are detected later and trx is restarted. Can't asan trigger false
> >> positives in this case?
> >
> > I can't imagine any.
> >
> >> Also, what is the order of instrumentation in tm+asan setting? I mean
> >> that neither tm must instrument asan instrumentation, nor asan must
> >> instrument tm instrumentation. Is it the case? There also can be
> >> conflicts related to ordering of instrumentation in the following
> >> case:
> >> asan_check();
> >> speculative_load();
> >> tm_check();
> >
> > I'm not aware of TM having speculative loads, libgtm certainly doesn't
> > install a SIGSEGV handler (and testing whether some memory is
> > readable/writable without actually dereferencing would be terribly slow).
> > If a memory load or store segfaults, whether in a transaction or outside of
> > it, it is a program bug and it is right if asan terminates the program.
> 
> 
> OK, thanks.
> AFAIR tl2 installs SIGSEGV and uses non-failing loads.

I think the original implementation didn't, but other TL2
implementations might if they want to avoid providing full privatization
safety without relying on any sandboxing attempts.  Sandboxing is hard
to get right (e.g., if the architecture doesn't provide nonfaulting
loads), and if you try it, you end up with a much more intrusive
solution (e.g., you need to ensure that the program doesn't override
your signal handlers).

Therefore, libitm ensures privatization safety by a quiescence-based
approach (i.e., a privatizing transaction waits until all other active
reading transactions are guaranteed to have observed the privatizer's
updates).

Torvald