Re: New ThreadSanitizer runtime (v3)

On Thu, 23 Dec 2021 at 13:10, Martin Liška wrote: > >> On 11/22/21 20:01, Dmitry Vyukov wrote: > >>> I've already reverted the change. So I will include a fix into the next > >>> version. > >>> Thanks for notifying. > >> > >> Hell

Re: New ThreadSanitizer runtime (v3)

On Mon, 29 Nov 2021 at 19:16, Martin Liška wrote: > > On 11/22/21 20:01, Dmitry Vyukov wrote: > > I've already reverted the change. So I will include a fix into the next > > version. > > Thanks for notifying. > > Hello. > > Am I correct that the patch set

Re: New ThreadSanitizer runtime (v3)

On Tue, 23 Nov 2021 at 17:16, Florian Weimer wrote: > > * Dmitry Vyukov: > > > On Tue, 23 Nov 2021 at 14:59, Florian Weimer wrote: > >> > >> * Dmitry Vyukov: > >> > >> > Or what kind of integration do you mean? Tsan did not have any dire

Re: New ThreadSanitizer runtime (v3)

On Tue, 23 Nov 2021 at 14:59, Florian Weimer wrote: > > * Dmitry Vyukov: > > > Or what kind of integration do you mean? Tsan did not have any direct > > integration and worked with unmodified glibc. > > I thought there is a false-positive data race report if an initi

Re: New ThreadSanitizer runtime (v3)

On Tue, 23 Nov 2021 at 14:49, Florian Weimer wrote: > > * Dmitry Vyukov via Gcc: > > > I wanted to give heads up regarding a significant re-design of the > > ThreadSanitizer runtime: > > https://reviews.llvm.org/D112603 > > Currently it's submitted: > > http

Re: New ThreadSanitizer runtime (v3)

On Mon, 22 Nov 2021 at 19:38, Martin Liška wrote: > > On 11/22/21 16:22, Dmitry Vyukov wrote: > > I wanted to give heads up regarding a significant re-design of the > > ThreadSanitizer runtime: > > https://reviews.llvm.org/D112603 > > Currently it's submitted: &g

Re: New ThreadSanitizer runtime (v3)

On Mon, 22 Nov 2021 at 19:31, Martin Liška wrote: > > On 11/22/21 16:22, Dmitry Vyukov wrote: > > Hi gcc developers, > > Hello. > > > > > I wanted to give heads up regarding a significant re-design of the > > Thanks for it. > > > ThreadSanitiz

New ThreadSanitizer runtime (v3)

Hi gcc developers, I wanted to give heads up regarding a significant re-design of the ThreadSanitizer runtime: https://reviews.llvm.org/D112603 Currently it's submitted: https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027 but can well be rolled back if too many

Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

On Sun, Feb 7, 2021 at 3:09 PM Kirill A. Shutemov wrote: > > On Sun, Feb 07, 2021 at 09:07:02AM +0100, Dmitry Vyukov wrote: > > On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu wrote: > > > > > > On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov > > > wrote: &g

Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu wrote: > > On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov > wrote: > > > > Provide prctl() interface to enabled LAM for user addresses. Depending > > how many tag bits requested it may result in enabling LAM_U57 or > > LAM_U48. > > I prefer the alternate

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

On Wed, May 13, 2020 at 12:48 PM Marco Elver wrote: > > Hello, Jakub, > > > > On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov wrote: > > > > > > On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote: > > > > > > > > On Tue, Apr 28, 2

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote: > > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote: > > FWIW this is: > > > > Acked-by: Dmitry Vyukov > > > > We just landed a similar change to llvm: > > h

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

y marked variables in the kernel, for > example bit-flags (here we may hide 'volatile' behind a different name > such as 'no_data_race'). > > [1] https://github.com/google/ktsan/wiki/KCSAN > [2] > https://lkml.kernel.org/r/CANpmjNOfXNE-Zh3MNP=-gmnhvKbsfUfTtWkyg_=vqtxs4nn...@mail.

Re: Add support to trace comparison instructions and switch statements

Some stats from kernel build for number of trace_cmp callbacks: gcc non-const: 38051 const: 272726 total: 310777 clang: non-const: 45944 const: 266299 total: 312243 The total is quite close. Gcc seems to emit more const callbacks, which is good. On Tue, Sep 12, 2017 at 4:32 PM, Dmitry Vyukov

Re: Add support to trace comparison instructions and switch statements

On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼) wrote: > Hi > The trace-div and trace-gep options seems be used to evaluate corpus > to trigger specific kind of bugs. And they don't have strong effect to > coverage. > > The trace-pc-guard is useful, but it may be much more complex

Re: Add support to trace comparison instructions and switch statements

patches > <gcc-patches@gcc.gnu.org>; Jeff Law <l...@redhat.com>; wishwu007 > <wishwu...@gmail.com> > Subject:Re: Add support to trace comparison instructions and switch statements > > > On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov <dvyu...@google.com> wr

Re: Add support to trace comparison instructions and switch statements

patches > <gcc-patc...@gcc.gnu.org>; Jeff Law <l...@redhat.com>; wishwu007 > <wishwu...@gmail.com> > Subject:Re: Add support to trace comparison instructions and switch statements > > > On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov <dvyu...@google.com> wr

Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>> What we instrument in LLVM is _comparisons_ rath

Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >>> What we instrument in LLVM is _comparisons_ rath

Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >> What we instrument in LLVM is _comparisons_ rather than control >> structures. So that would be: >> _4 = x_8(D) ==

Re: Add support to trace comparison instructions and switch statements

On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote: >> What we instrument in LLVM is _comparisons_ rather than control >> structures. So that would be: >> _4 = x_8(D) ==

Re: Add support to trace comparison instructions and switch statements

tionalized. > > @@ -1943,6 +2032,12 @@ common_handle_option (struct gcc_options *opts, > &= ~(SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT); >break; > > +case OPT_fsanitize_coverage_: > + opts->x_flag_sanitize_coverage > + = parse_coverage_sanitizer_options (arg, loc,

Re: Add support to trace comparison instructions and switch statements

tionalized. > > @@ -1943,6 +2032,12 @@ common_handle_option (struct gcc_options *opts, > &= ~(SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT); >break; > > +case OPT_fsanitize_coverage_: > + opts->x_flag_sanitize_coverage > + = parse_coverage_sanitizer_options (arg, loc,

Re: Add support to trace comparison instructions and switch statements

On Sat, Aug 5, 2017 at 11:53 AM, 吴潍浠(此彼) wrote: > Hi all > Is it worth adding my codes to gcc ? Are there some steps I need to do ? > Could somebody tell me the progress ? FYI, we've mailed a Linux kernel change that uses this instrumentation:

Re: Add support to trace comparison instructions and switch statements

On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼) wrote: > Hi > > Implementing __sanitizer_cov_trace_cmp[1248]_const is OK . > And I will try to find some determinate way to judge this comparison is for > loop or not. > Because all the loops(for() or while()) seem to be transformed

Re: Add support to trace comparison instructions and switch statements

On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼) wrote: > Hi > > Implementing __sanitizer_cov_trace_cmp[1248]_const is OK . > And I will try to find some determinate way to judge this comparison is for > loop or not. > Because all the loops(for() or while()) seem to be transformed

Re: Add support to trace comparison instructions and switch statements

On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote: > Hi > > I wrote a test for "-fsanitize-coverage=trace-cmp" . > > Is there anybody tells me if these codes could be merged into gcc ? Nice! We are currently working on

Re: Add support to trace comparison instructions and switch statements

On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote: > Hi > > I wrote a test for "-fsanitize-coverage=trace-cmp" . > > Is there anybody tells me if these codes could be merged into gcc ? Nice! We are currently working on

Re: Add support to trace comparison instructions and switch statements

On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote: >> > Hi >> > >> > I wrote a test for "-fsanitize-coverage=trace-cmp" . >> > >> > Is there anybody tells me if these codes could be merged into gcc ? >> >> >> Nice! >> >> We are currently working on Linux kernel fuzzing

Re: Add support to trace comparison instructions and switch statements

On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote: >> > Hi >> > >> > I wrote a test for "-fsanitize-coverage=trace-cmp" . >> > >> > Is there anybody tells me if these codes could be merged into gcc ? >> >> >> Nice! >> >> We are currently working on Linux kernel fuzzing

Re: Add support to trace comparison instructions and switch statements

t; and ">" all of them are >> meaningful, because programmers must have some reasons to do that. As >> practice , "==" is more meaningful. >> >> 4.Should we record comparisons for counting loop checks ? >> Not sure. >> >> With

Re: Add support to trace comparison instructions and switch statements

t; and ">" all of them are >> meaningful, because programmers must have some reasons to do that. As >> practice , "==" is more meaningful. >> >> 4.Should we record comparisons for counting loop checks ? >> Not sure. >> >> With

Re: Add support to trace comparison instructions and switch statements

On Tue, Jul 11, 2017 at 1:59 PM, Wish Wu wrote: > Hi > > I wrote a test for "-fsanitize-coverage=trace-cmp" . > > Is there anybody tells me if these codes could be merged into gcc ? Nice! We are currently working on Linux kernel fuzzing that use the comparison tracing. We

Re: Add support to trace comparison instructions and switch statements

On Tue, Jul 11, 2017 at 1:59 PM, Wish Wu wrote: > Hi > > I wrote a test for "-fsanitize-coverage=trace-cmp" . > > Is there anybody tells me if these codes could be merged into gcc ? Nice! We are currently working on Linux kernel fuzzing that use the comparison tracing. We

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

On Wed, Dec 7, 2016 at 10:57 PM, Sandra Loosemore <san...@codesourcery.com> wrote: > On 12/07/2016 12:30 PM, Dmitry Vyukov wrote: >> >> On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore >> <san...@codesourcery.com> wrote: >>> >>> >>> Yo

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore <san...@codesourcery.com> wrote: > On 12/07/2016 11:44 AM, Dmitry Vyukov wrote: >> >> Hello, >> >> Revision 241896 added -fsanitize-address-use-after-scope and enabled >> it whenever any sanitizer is enabled. T

[PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

-after-scope for e.g. -fsanitize=thread, which is I believe unnecessary. OK for trunk? Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 243344) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2016-12-07 Dmitry Vyukov <d

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 8:22 PM, Mike Stump wrote: > On Feb 15, 2016, at 3:29 AM, Bernd Edlinger wrote: >> And independently of that I am looking at using llvm's test.h framework >> instead >> of gcc's test_barrier.h for gcc-7 soon. > > Here’s

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 1:44 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 15/02/16 13:05, Dmitry Vyukov wrote: >> On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger >> <bernd.edlin...@hotmail.de> wrote: >>> >>> No problem. PR65400 was a

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 15/02/16 08:18, Dmitry Vyukov wrote: >> llvm tsan tests contain test.h file (probably what's called >> test_barrier.h in gcc), you can put the macro there. test.h should >> already

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 11:45 AM, Tom de Vries <tom_devr...@mentor.com> wrote: > On 15/02/16 10:07, Bernd Edlinger wrote: >> >> On 15/02/16 09:07, Tom de Vries wrote: >>>> >>>> >>On 15/02/16 08:24, Dmitry Vyukov wrote: >>>> &

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 10:07 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 15/02/16 09:07, Tom de Vries wrote: >>>On 15/02/16 08:24, Dmitry Vyukov wrote: >>> >>>If we are talking about pr 68580, then I would try: >>>https://

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

If we are talking about pr 68580, then I would try: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2 first. On Mon, Feb 15, 2016 at 8:18 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries <tom_devr...@mentor.com> wrote: >> H

Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries wrote: > Hi, > > Occasionally, I've been running into this failure while running the tsan > testsuite: > ... > FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test > ... > > I've also observed a potential similar occurrence

Re: [PATCH] Fix new sancov tests

On Mon, Dec 7, 2015 at 4:20 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Dec 07, 2015 at 04:16:02PM +0100, Dmitry Vyukov wrote: >> Index: ChangeLog >> === >> --- ChangeLog (revision 231362) >

Re: [PATCH] Fix new sancov tests

On Mon, Dec 7, 2015 at 2:56 PM, Nathan Sidwell <nat...@acm.org> wrote: > On 12/06/15 03:56, Dmitry Vyukov wrote: >> >> Hello, >> >> Sancov tests submitted in 231296 assume that asan is supported on all >> platforms. >> This patch fixes that assumption.

Re: [PATCH] Fix new sancov tests

On Mon, Dec 7, 2015 at 3:09 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Sun, Dec 06, 2015 at 09:56:32AM +0100, Dmitry Vyukov wrote: > >> --- gcc.dg/sancov/sancov.exp (revision 231328) >> +++ gcc.dg/sancov/sancov.exp (working copy) >> @@ -18,6 +18,7 @@ >>

[PATCH] Fix new sancov tests

@@ +2015-12-06 Dmitry Vyukov <dvyu...@google.com> + + * gcc.dg/sancov/sancov.exp: Don't run asan tests when asan is not + available. + 2015-12-05 David Edelsohn <dje@gmail.com> * gcc.target/powerpc/recip-sqrtf.c: New test. Index: gcc.dg/sanco

Re: Add fuzzing coverage support

On Sat, Dec 5, 2015 at 1:54 AM, Nathan Sidwell <nat...@acm.org> wrote: > On 12/04/15 13:28, Dmitry Vyukov wrote: >> >> On Fri, Dec 4, 2015 at 6:39 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>> >>> On Fri, Dec 04, 2015 at 06:32:38PM +0100, Dmitry Vyuko

Re: Add fuzzing coverage support

ther coverage modes are backed by sanitizer_common runtime and libFuzzer, which together allow to do efficient in-process fuzzing. We don't have plans to port other options at the moment per se. Though, that's doable and we could sync sanitizer library for runtime support. > On Thu, Dec 03, 2015 a

Re: Add fuzzing coverage support

VM alternatives to GCC's gcov/-fprofile-generate etc.? >> >> On Thu, Dec 03, 2015 at 08:17:06PM +0100, Dmitry Vyukov wrote: >>> >>> +unsigned sancov_pass (function *fun) >> >> >> Formatting: >> unsigned >> sancov_pass (function *fun) >>

Re: Add fuzzing coverage support

On Fri, Dec 4, 2015 at 6:39 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Dec 04, 2015 at 06:32:38PM +0100, Dmitry Vyukov wrote: >> +2015-12-04 Dmitry Vyukov <dvyu...@google.com> >> + >> + * sancov.c: New file. >> + * Makefile.in (OBJS

Re: Add fuzzing coverage support

On Thu, Dec 3, 2015 at 7:34 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > I've attached updated patch (also reuploaded > https://codereview.appspot.com/280140043). > Fixed ChangeLog. > Added invoke.texi. > Fixed style issues. > > The function is defined only in kerne

Re: Add fuzzing coverage support

@@ +2015-12-03 Dmitry Vyukov <dvyu...@google.com> + + * sancov.c: New file. + * Makefile.in (OBJS): Add sancov.o. + * invoke.texi (-fsanitize-coverage=trace-pc): Describe. + * passes.def (sancov_pass): Add. + * tree-pass.h (sancov_pass): Add. + * common.opt (-fsanitize-coverage=trace-pc

[PATCH^1] Add fuzzing coverage support

On Wed, Dec 2, 2015 at 5:10 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > ping > > Number of bugs found with this coverage in kernel already crossed 40: > https://github.com/google/syzkaller/wiki/Found-Bugs > > > > > On Fri, Nov 27, 2015 at 3:30 PM, Dmitry

Re: Add fuzzing coverage support

ping Number of bugs found with this coverage in kernel already crossed 40: https://github.com/google/syzkaller/wiki/Found-Bugs On Fri, Nov 27, 2015 at 3:30 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > +syzkaller group > > On Fri, Nov 27, 2015 at 3:28 PM, Dmitry Vyukov <

Re: Add fuzzing coverage support

On Wed, Dec 2, 2015 at 5:47 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 12/02/2015 05:10 PM, Dmitry Vyukov wrote: >> >> ping > > > I do not see the original submission in my archives. That's strange. I don't see it in gcc-patches archives as well. The origina

Re: Add fuzzing coverage support

On Wed, Dec 2, 2015 at 6:11 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > On 12/02/2015 05:55 PM, Dmitry Vyukov wrote: >> >> Can you point to some concrete coding style violations (besides >> function comments)? >> >> (flag_sanitiz

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On Wed, Sep 2, 2015 at 12:58 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Tue, 1 Sep 2015, Dmitry Vyukov wrote: > >> The refcounted basic_string implementation contains several data races >> on _M_refcount: > > > There are several bug reports about races

Re: [Patch, libstdc++] Fix data races in basic_string implementation

Added comment to _M_dispose and restored ChangeLog entry. Please take another look. On Wed, Sep 2, 2015 at 3:17 PM, Jonathan Wakely <jwak...@redhat.com> wrote: > On 01/09/15 17:42 +0200, Dmitry Vyukov wrote: >> >> On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely <jwak

Re: [Patch, libstdc++] Fix data races in basic_string implementation

wrote: > On 02/09/15 16:01 +0200, Dmitry Vyukov wrote: >> >> Added comment to _M_dispose and restored ChangeLog entry. >> Please take another look. > > > Thanks, this is OK for trunk. > > I assume you are covered by the Google company-wide copyright > assignment

[Patch, libstdc++] Fix data races in basic_string implementation

Hello, The refcounted basic_string implementation contains several data races on _M_refcount: 1. _M_is_leaked loads _M_refcount concurrently with mutations of _M_refcount. This loads needs to be memory_order_relaxed load, as _M_is_leaked predicate does not change under the feet. 2. _M_is_shared

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On Tue, Sep 1, 2015 at 4:27 PM, Jonathan Wakely <jwak...@redhat.com> wrote: > On 01/09/15 14:51 +0200, Dmitry Vyukov wrote: >> >> Hello, >> >> The refcounted basic_string implementation contains several data races >> on _M_refcount: >> 1. _M_is_leaked

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely <jwak...@redhat.com> wrote: > On 01/09/15 16:56 +0200, Dmitry Vyukov wrote: >> >> I don't understand how a new gcc may not support __atomic builtins on >> ints. How it is even possible? That's a portable API

Re: [PATCH] Add support for exceptions to tsan (PR sanitizer/64265)

Hi Jakub, Do you plan to move forward with this patch? Is it waiting to be reviewed? People keep asking about exception support for tsan (I guess it is critical for a significant potion of C++ out there). I am trying to sketch support in llvm. And I am leaning towards an approach similar to

Re: [PATCH] Add support for exceptions to tsan (PR sanitizer/64265)

On Sat, Jun 27, 2015 at 7:12 PM, Jakub Jelinek ja...@redhat.com wrote: On Sat, Jun 27, 2015 at 04:53:22PM +0200, Dmitry Vyukov wrote: Do you plan to move forward with this patch? Is it waiting to be reviewed? People keep asking about exception support for tsan (I guess it is critical

Re: [PATCH, TSAN] Fix a crash in ScopedReport::AddThread

OK On Wed, Mar 11, 2015 at 5:41 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi Jakub, with my OPC UA Server, I observe a reproducible crash in ScopedReport::AddThread: tctx==NULL in if ((u32)rep_-threads[i]-id == tctx-tid). Apparently, Dmitry has already fixed that in the obvious

Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN

On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

On Wed, Jan 21, 2015 at 11:34 AM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 21, 2015 at 12:23:34PM +0400, Dmitry Vyukov wrote: Hi Mike, Yes, I can quantify the cost. Is it very high. Here is the patch that I used: --- rtl/tsan_rtl.cc (revision 226644) +++ rtl/tsan_rtl.cc (working

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote: [text-only] On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump mikest...@comcast.net wrote: On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov dvyu

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

] DISABLED_BENCH.Mop8Write (5085 ms) So that's 338% slowdown. On Mon, Jan 19, 2015 at 6:12 PM, Mike Stump mikest...@comcast.net wrote: On Jan 19, 2015, at 12:47 AM, Dmitry Vyukov dvyu...@google.com wrote: Long story short. Tsan has a logical data race the core of data race detection algorithm. The race

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

Well, OK, it is actually not easier to write tests with step function as compared to barrier. On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov dvyu...@google.com wrote: On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Mon, 19 Jan 2015 18:49:21

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

On Wed, Jan 21, 2015 at 5:38 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote: Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update To: bernd.edlin...@hotmail.de CC: konstantin.s.serebry...@gmail.com; mikest...@comcast.net; k

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

inside of pthread_cond_wait; or when a thread needs to process signals. But all remaining uses of sleep are commented. On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov dvyu...@google.com wrote: On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Mon, 19 Jan

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

Long story short. Tsan has a logical data race the core of data race detection algorithm. The race is not a bug, but a deliberate design decision that makes tsan considerably faster. So ironically, if the race memory accesses happen almost simultaneously, tsan can miss the race. Thus we have

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote: This is just a copy from llvm repo, right? Looks good to me. Thanks. Yes I found these test case in the llvm tree, and just adapted them to work

Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update

This is just a copy from llvm repo, right? Looks good to me. On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, I think I should ping for this patch now: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html note that by mistake the change log

Re: [PATCH] Fix parameters of __tsan_vptr_update

Hi, Sorry for the delay, I was on a vacation. Is here anything to do/review for me? On Sun, Jan 11, 2015 at 4:15 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote: Hi Jakub, I think I have found a reasonable test case, see the

Re: [PATCH] Instrument bit field and unaligned accesses for TSAN

Cool! Thanks. Gcc is again ahead of clang :) On Sat, Jan 3, 2015 at 1:11 AM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jan 02, 2015 at 11:01:56PM +0100, Bernd Edlinger wrote: gcc/ChangeLog: 2015-01-02 Bernd Edlinger bernd.edlin...@hotmail.de Instrument bit field and unaligned

Re: [PATCH] Add support for exceptions to tsan (PR sanitizer/64265)

I am not qualified to review the actual code changes, but from the description it looks good to me. It adds a EH frame to every function, right? In 64-bit mode there is no runtime penalty, right? Do you have any idea about binary size increase? Does gcc build in C++ mode nowadays? It can be a

Re: [PATCH] Add support for exceptions to tsan (PR sanitizer/64265)

Cross referenced this patch from https://code.google.com/p/thread-sanitizer/issues/detail?id=78 On Tue, Dec 16, 2014 at 12:25 PM, Dmitry Vyukov dvyu...@google.com wrote: I am not qualified to review the actual code changes, but from the description it looks good to me. It adds a EH frame

Re: [PINGv2][PATCH] Ignore alignment by option

+address-sanitizer Please don't hurry with it. Do you have any numbers on how frequent are unaligned accesses in kernel? Is it worth addressing at this cost? size_in_bytes = -1 instrumentation is too slow to be the default in kernel. If we want to pursue this, I propose a different scheme.

Re: [PINGv2][PATCH] Ignore alignment by option

On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov y.gri...@samsung.com wrote: On 12/04/2014 03:47 PM, Dmitry Vyukov wrote: size_in_bytes = -1 instrumentation is too slow to be the default in kernel. If we want to pursue this, I propose a different scheme. Handle 8+ byte accesses as 1/2/4 accesses

Re: [PINGv2][PATCH] Ignore alignment by option

On Thu, Dec 4, 2014 at 5:16 PM, Yury Gribov y.gri...@samsung.com wrote: On 12/04/2014 05:04 PM, Dmitry Vyukov wrote: On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov y.gri...@samsung.com wrote: On 12/04/2014 03:47 PM, Dmitry Vyukov wrote: size_in_bytes = -1 instrumentation is too slow

Re: asan: support for globals in kernel

On Wed, Dec 3, 2014 at 9:19 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 12/02/2014 08:56 PM, Dmitry Vyukov wrote: Hi, The following patch adds support for instrumentation of globals for Linux kernel (-fsanitize=kernel-address). Kernel only supports constructors with default priority

Re: asan: support for globals in kernel

will wait for Andrey this time On Thu, Dec 4, 2014 at 10:12 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Dec 04, 2014 at 11:10:15PM +0400, Dmitry Vyukov wrote: That would be an option too. I don't know whether it is much better or not. Kernel lives without constructors, they are used

asan: support for globals in kernel

=== --- gcc/ChangeLog (revision 218280) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2014-12-02 Dmitry Vyukov dvyu...@google.com + + * asan.c: (asan_finish_file): Use default priority for constructors + in kernel mode. + 2014-12-02 Ulrich Weigand

Re: asan: support for globals in kernel

On Tue, Dec 2, 2014 at 9:04 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Dec 02, 2014 at 09:56:36PM +0400, Dmitry Vyukov wrote: --- gcc/ChangeLog (revision 218280) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,8 @@ +2014-12-02 Dmitry Vyukov dvyu...@google.com + + * asan.c

Re: asan: support for globals in kernel

On Tue, Dec 2, 2014 at 9:17 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Dec 02, 2014 at 10:12:30PM +0400, Dmitry Vyukov wrote: Shall we backport it to 4.9 branch too? If it's doable, it would be nice. Thanks. Bet the same patch will just apply there. Do I need to do anything

Re: [PATCH] Allow -fsanitize=thread without -pie

Looks good to me. Thanks! On Wed, Nov 26, 2014 at 10:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Nov 21, 2014 at 04:20:44PM +0400, Dmitry Vyukov wrote: Yes, I think it's the way to go. I've just committed the following revision to clang that removes -pie when compiling with tsan

Re: libsanitizer merge from upstream r221802

On Thu, Nov 13, 2014 at 12:16 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote: Here is one more merge of libsanitizer (last one was in Sept). Tested on x86_64 Ubuntu 14.04 like this: rm -rf */{*/,}libsanitizer make -j 50 make

Re: [PATCHv4] Enable -fsanitize-recover for KASan

On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov y.gri...@samsung.com wrote: On 10/23/2014 03:10 PM, Andrey Ryabinin wrote: On 10/23/2014 02:38 PM, Jakub Jelinek wrote: On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote: Actually this is a historical artifact. If inlining proves to

Re: [PATCHv4] Enable -fsanitize-recover for KASan

On Fri, Oct 24, 2014 at 1:50 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote: I am somewhat lost in this thread and probably missing something. But why do we need __asan_load (which is not noabort) at all? Outline instrumentation is non

Re: [PATCHv4] Enable -fsanitize-recover for KASan

On Fri, Oct 24, 2014 at 1:59 PM, Yury Gribov y.gri...@samsung.com wrote: On 10/24/2014 01:44 PM, Dmitry Vyukov wrote: On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov y.gri...@samsung.com wrote: On 10/23/2014 03:10 PM, Andrey Ryabinin wrote: On 10/23/2014 02:38 PM, Jakub Jelinek wrote

Re: Backporting KAsan patches to 4.9 branch

On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov y.gri...@samsung.com wrote: On 09/18/2014 01:57 PM, Jakub Jelinek wrote: On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote: Kernel Asan patches are currently being discussed in LKML. One of the points raised during review was that KAsan

Re: [PATCH] Disable __asan_init for KASan

Looks good to me On Fri, Oct 3, 2014 at 5:07 PM, Yury Gribov y.gri...@samsung.com wrote: Hi all, This patch disables generation of asan_init calls for KASan as discussed in https://lkml.org/lkml/2014/9/26/711 Bootstrapped and regtested no x64. Ok to commit? -Y commit

Re: msan and gcc ?

On Wed, Oct 1, 2014 at 11:30 AM, VandeVondele Joost joost.vandevond...@mat.ethz.ch wrote: Hi, I've noticed that gcc includes a msan_interface.h file, and I'm wondering if this implies that memory sanitizer is already part of gcc. If not, are there plans to port this useful looking tool to

Re: [RFC] Add asm constraint modifier to mark strict memory accesses

On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov y.gri...@samsung.com wrote: On 09/18/2014 09:33 PM, Dmitry Vyukov wrote: What is the number of cases it will fix for kasan? Re-added kernel people again. AFAIR silly instrumentation that assumed all memory accesses in inline asm are must

Re: [RFC] Add asm constraint modifier to mark strict memory accesses

On Thu, Sep 18, 2014 at 4:09 AM, Yury Gribov y.gri...@samsung.com wrote: Hi all, Current semantics of memory constraints in GCC inline asm (i.e. m, v, etc.) is somewhat loosy in that it tells GCC that asm code _may_ access given amount of bytes but is not guaranteed to do so. This is (ab)used

Re: [PATCH] Enable -fsanitize-recover for KASan

On Fri, Sep 5, 2014 at 10:54 AM, Yury Gribov y.gri...@samsung.com wrote: Hi all, This patch enables -fsanitize-recover for KASan by default. This causes KASan to continue execution after error in case of inline instrumentation. This feature is needed because - reports during early bootstrap

  1   2   >