Page MenuHomePhabricator
Feed Advanced Search

Wed, Feb 13

dvyukov updated subscribers of D54889: Fiber support for thread sanitizer.

CC @Yi-Hong.Lyu

Wed, Feb 13, 8:46 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I see a similar failure was already reported:
https://reviews.llvm.org/D54889#1394632
There was no fix for it, right? Or did I forgot to squash something else?

Wed, Feb 13, 8:45 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
  • Forwarded message ---------

From: Yi-Hong Lyu via Phabricator <reviews@reviews.llvm.org>
Date: Wed, Feb 13, 2019 at 5:33 PM
Subject: [Diffusion] rL353817: tsan: add fiber support

Wed, Feb 13, 8:42 AM · Restricted Project, Restricted Project
dvyukov committed rG76e961207bd1: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Wed, Feb 13, 5:21 AM
dvyukov closed D58171: Fix thread sanitizer on aarch64.

This is submitted as part of 353947

Wed, Feb 13, 5:21 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353947: .
Wed, Feb 13, 5:21 AM
dvyukov committed rL353947: .
Wed, Feb 13, 5:21 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Resubmitted in 353947 with 2 fixes squashed.

Wed, Feb 13, 5:21 AM · Restricted Project, Restricted Project
dvyukov accepted D58171: Fix thread sanitizer on aarch64.

Looks good to me.

Wed, Feb 13, 4:36 AM · Restricted Project, Restricted Project

Tue, Feb 12

dvyukov added a comment to D58110: Support fiber API on macOS.

Kuba, please take a look. This mostly touches Mac-specific files. I can't test this.

Tue, Feb 12, 2:39 AM · Restricted Project, Restricted Project
dvyukov committed rG19e41fb0ca4d: tsan: update check_analyze.sh (authored by dvyukov).
tsan: update check_analyze.sh
Tue, Feb 12, 2:18 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR updated check_analyze.sh in http://llvm.org/viewvc/llvm-project?view=revision&revision=353820

Tue, Feb 12, 2:18 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Tue, Feb 12, 2:18 AM
dvyukov committed rL353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Tue, Feb 12, 2:18 AM
dvyukov closed D54889: Fiber support for thread sanitizer.

Committed in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=353817

Tue, Feb 12, 2:14 AM · Restricted Project, Restricted Project
dvyukov committed rG6e7089ad4036: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Tue, Feb 12, 2:12 AM
dvyukov committed rCRT353817: tsan: add fiber support.
tsan: add fiber support
Tue, Feb 12, 2:12 AM
dvyukov accepted D54889: Fiber support for thread sanitizer.
Tue, Feb 12, 2:12 AM · Restricted Project, Restricted Project
dvyukov committed rL353817: tsan: add fiber support.
tsan: add fiber support
Tue, Feb 12, 2:12 AM
dvyukov added inline comments to D58108: [sanitizer]: fix warnings reported by SVACE static analyzer..
Tue, Feb 12, 1:25 AM · Restricted Project, Restricted Project
dvyukov committed rGca524b19c152: tsan: Introduce in_symbolizer() function for Thread sanitizer (authored by dvyukov).
tsan: Introduce in_symbolizer() function for Thread sanitizer
Tue, Feb 12, 12:12 AM
dvyukov committed rCRT353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Tue, Feb 12, 12:11 AM
dvyukov committed rL353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Tue, Feb 12, 12:11 AM
dvyukov closed D58104: Introduce in_symbolizer() function for Thread sanitizer.

Submitted in 353805.

Tue, Feb 12, 12:10 AM · Restricted Project, Restricted Project
dvyukov accepted D58104: Introduce in_symbolizer() function for Thread sanitizer.

Perfect! Thanks!
Testing and submitting.

Tue, Feb 12, 12:08 AM · Restricted Project, Restricted Project

Mon, Feb 11

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

However, for thread initialization we rely on the fact that pthread's thread entry function (start_thread) calls _setjmp which we intercept. If start_thread does not call _setjmp then we risk to hit NULL cur_thread in secondary threads. I think we need to add cur_thread_init also to:

  1. SCOPED_INTERCEPTOR_RAW (this will ensure that if start_thread calls any intercepted libc function, we will init at that point)

There is a lot if interceptors that do

if (cur_thread()->in_symbolizer)

before SCOPED_INTERCEPTOR_RAW. What to do with them?

Mon, Feb 11, 6:47 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

The change is now a very good shape.

Mon, Feb 11, 4:05 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

macOS is fixed.
Test on ppc64 is disabled — pthread_exit does not work there without any interceptors.

Mon, Feb 11, 2:02 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

Mon, Feb 11, 1:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to rL353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.

Hi Yi-Hong,
Let's move the discussion to https://reviews.llvm.org/D57876 because there is already some.

Mon, Feb 11, 1:32 AM

Fri, Feb 8

dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

One thing that I noticed is that pthread_exit is a noreturn function and SCOPED_TSAN_INTERCEPTOR creates a local object with destructor. At the very least this leads to confusing code where readers assumption is that the destructor will run, but it will not.
Perhaps we should try to remove the SCOPED_TSAN_INTERCEPTOR entirely as the CHECK that we want to add here does not need it.

Fri, Feb 8, 12:22 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.
  • Forwarded message ---------

From: Alex L
Date: Fri, Feb 8, 2019 at 1:17 AM
Subject: Re: [compiler-rt] r353385 - tsan: Implement pthread_exit() interceptor for Thread sanitizer

Fri, Feb 8, 12:13 AM · Restricted Project, Restricted Project

Thu, Feb 7

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

To clarify the graph: it's difference in execution time in percents as compared to the current HEAD. I.e. -4 means that fibers are 4% slower than the current HEAD.
1w means mop.cc benchmark with 1-byte write accesses; 4r - 4-byte read accesses. ee is func_entry_exit.cc benchmark.

Thu, Feb 7, 9:37 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Did another round of benchmarking of this change on the current HEAD using these 2 benchmarks:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/mop.cc
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/func_entry_exit.cc

Thu, Feb 7, 9:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Current code runs in 7.16s
This change -- 6.23s
This change + cur_thread_fast returning cur_thread_placeholder -- 7.01s
I also tried this change + FuncEntry using cur_thread_fast -- 6.20s

But if I do:

INLINE ThreadState *cur_thread_fast() {
  ThreadState* thr;
  __asm__("": "=a"(thr): "a"(&cur_thread_placeholder[0]));
  return thr;
}

(which is a dirty trick to force compiler to cache address of the tls object in a register) then the program runs 5.94s -- faster than any other options as it takes advantage of both no indirection and faster instructions.

Thu, Feb 7, 6:09 AM · Restricted Project, Restricted Project
dvyukov committed rGbdfba86047cd: tsan: add more benchmarks (authored by dvyukov).
tsan: add more benchmarks
Thu, Feb 7, 6:05 AM
dvyukov committed rCRT353407: tsan: add more benchmarks.
tsan: add more benchmarks
Thu, Feb 7, 6:04 AM
dvyukov committed rL353407: tsan: add more benchmarks.
tsan: add more benchmarks
Thu, Feb 7, 6:04 AM
dvyukov closed D57882: Optimize performance of Thread sanitizer memory access functions.

Committed in 353401
http://llvm.org/viewvc/llvm-project?view=revision&revision=353401

Thu, Feb 7, 4:44 AM · Restricted Project, Restricted Project
dvyukov committed rGfddaf1f369a1: tsan: Optimize performance of Thread sanitizer memory access functions (authored by dvyukov).
tsan: Optimize performance of Thread sanitizer memory access functions
Thu, Feb 7, 4:44 AM
dvyukov committed rCRT353401: tsan: Optimize performance of Thread sanitizer memory access functions.
tsan: Optimize performance of Thread sanitizer memory access functions
Thu, Feb 7, 4:43 AM
dvyukov committed rL353401: tsan: Optimize performance of Thread sanitizer memory access functions.
tsan: Optimize performance of Thread sanitizer memory access functions
Thu, Feb 7, 4:43 AM
dvyukov accepted D57882: Optimize performance of Thread sanitizer memory access functions.
Thu, Feb 7, 4:40 AM · Restricted Project, Restricted Project
dvyukov committed rGbaf2f35ec4c5: sanitizers: Introduce ThreadType enum (authored by dvyukov).
sanitizers: Introduce ThreadType enum
Thu, Feb 7, 3:02 AM
dvyukov closed D57839: Introduce ThreadType enum.
Thu, Feb 7, 3:01 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57839: Introduce ThreadType enum.

Committed in 353390
http://llvm.org/viewvc/llvm-project?view=revision&revision=353390

Thu, Feb 7, 3:01 AM · Restricted Project, Restricted Project
dvyukov committed rL353390: sanitizers: Introduce ThreadType enum.
sanitizers: Introduce ThreadType enum
Thu, Feb 7, 3:01 AM
dvyukov committed rCRT353390: sanitizers: Introduce ThreadType enum.
sanitizers: Introduce ThreadType enum
Thu, Feb 7, 3:01 AM
dvyukov accepted D57839: Introduce ThreadType enum.
Thu, Feb 7, 3:00 AM · Restricted Project, Restricted Project
dvyukov committed rG17132b62e037: tsan: Implement pthread_exit() interceptor for Thread sanitizer (authored by dvyukov).
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Thu, Feb 7, 2:46 AM
dvyukov closed D57876: Implement pthread_exit() interceptor for Thread sanitizer.

Committed in 353385
http://llvm.org/viewvc/llvm-project?view=revision&revision=353385

Thu, Feb 7, 2:46 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Thu, Feb 7, 2:46 AM
dvyukov committed rL353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.
tsan: Implement pthread_exit() interceptor for Thread sanitizer
Thu, Feb 7, 2:45 AM
dvyukov accepted D57876: Implement pthread_exit() interceptor for Thread sanitizer.
Thu, Feb 7, 2:43 AM · Restricted Project, Restricted Project

Wed, Feb 6

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Going forward I think we should get in all unrelated/preparatory changed first: thread type (creates lots of diffs), pthread_exit interceptor/test and spot optimizations to memory access functions.

Wed, Feb 6, 7:07 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Current code runs in 7.16s
This change -- 6.23s
This change + cur_thread_fast returning cur_thread_placeholder -- 7.01s
I also tried this change + FuncEntry using cur_thread_fast -- 6.20s

Wed, Feb 6, 6:53 AM · Restricted Project, Restricted Project

Tue, Feb 5

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Also benchmarked function entry/exit using the following benchmark:

Tue, Feb 5, 7:20 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Since fiber support incurs slowdown for all current tsan users who don't use fibers, this is a hard decision.

Tue, Feb 5, 6:15 AM · Restricted Project, Restricted Project
Herald added a project to D54889: Fiber support for thread sanitizer: Restricted Project.

Spent a while benchmarking this. I used 4 variations of a test program:
First just does read or write access of the given size:
https://gist.githubusercontent.com/dvyukov/9155651ecb9434368f06a30df2abcb20/raw/c0756a9d643718faaacda2c78ace1cb95f05af87/gistfile1.txt
Second, prepopulates shadow with some other accesses first:
https://gist.githubusercontent.com/dvyukov/12b4ca0a15ffccccdaf9e92d20df40e2/raw/a2cdfc65fccf1eecdc232c876dc45e41229f6ce1/gistfile1.txt
Next has 2 threads that access the range in round-robin, both threads do writes (or reads):
https://gist.githubusercontent.com/dvyukov/0d84c9d9795cbbd8b9b9bb557d1e2f36/raw/24dcdf48f39cd12ac77ae71e9de7f8ee01c17df2/gistfile1.txt
The last one has 1 threads that does writes, followed by 2 threads that do reads:
https://gist.githubusercontent.com/dvyukov/1efa2c0335d9d944b33857dbd70cb8ce/raw/6eff5ea186fd5d8540090faaf344ad66250c6e5e/gistfile1.txt

Tue, Feb 5, 6:11 AM · Restricted Project, Restricted Project

Mon, Jan 21

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Now, when all performance issues are resolved, what else should be done to complete the review?

Mon, Jan 21, 9:52 AM · Restricted Project, Restricted Project

Jan 10 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Benchmark results with clang:

Jan 10 2019, 9:47 AM · Restricted Project, Restricted Project

Jan 8 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I improved test execution time. On my system I got following execution times (compared to original version of code):

compilercurrentfibers
gcc 8.2100.0%98.6%
clang112.4%100.7%

"current" is compiler-rt HEAD with no local changes, or with the previous version of this change? This makes clang-compiled runtime 12% faster?
Were you able to reproduce the slowdown in https://reviews.llvm.org/D54889#1343582 with the previous version of the fibers change? What slowdown did you get?

Jan 8 2019, 1:49 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I improved test execution time. On my system I got following execution times (compared to original version of code):

compilercurrentfibers
gcc 8.2100.0%98.6%
clang112.4%100.7%
Jan 8 2019, 1:44 AM · Restricted Project, Restricted Project

Jan 7 2019

dvyukov accepted D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Jan 7 2019, 11:10 AM · Restricted Project

Jan 6 2019

dvyukov added inline comments to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Jan 6 2019, 10:12 PM · Restricted Project

Jan 4 2019

dvyukov added inline comments to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.
Jan 4 2019, 1:24 AM · Restricted Project
dvyukov accepted D56295: [TSan] Use switches when dealing with enums.
Jan 4 2019, 1:10 AM · Restricted Project

Jan 3 2019

dvyukov added a comment to D56238: [TSan] Support Objective-C @synchronized with tagged pointers.

What are tagged pointers? When they are used? What is the actual value? How does synchronized handle them? Is there a man page or something with more info? It should be included in the comment for future generations.

Jan 3 2019, 12:55 AM · Restricted Project

Jan 2 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I've benchmarked on 350140 with host gcc version 7.3.0 (Debian 7.3.0-5), running old/new binary alternated:

Jan 2 2019, 6:58 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Re performance, we have this open performance regression in clang codegen which makes it harder to do analysis:
https://bugs.llvm.org/show_bug.cgi?id=39748
https://reviews.llvm.org/D54821

Jan 2 2019, 6:22 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I added default synchronization and flag to opt-out.

Can you swicth to it in your codebase? I would expect that you need all (or almost all) of this synchronization anyway?

Unfortunately, I can't check it. Current implementation of our codebase work fine with synchronization on fiber switch.

I plan to implement another mode when fibers are not synchronized by default, but only when they call special synchronization APIs (events, mutexes etc.). Such way I can catch more errors in code when fibers are running in the same thread only by chance. In order to implement it, I need some way to opt-out of synchronization in tsan.

Jan 2 2019, 6:22 AM · Restricted Project, Restricted Project
dvyukov accepted D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.
Jan 2 2019, 5:40 AM
dvyukov added inline comments to D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.
Jan 2 2019, 4:01 AM

Dec 30 2018

dvyukov added a comment to D56157: [sanitizer_common] Implement popen, popenve, pclose interceptors.

This needs some tests, at least to exercise interceptors code once.

Dec 30 2018, 8:05 PM
dvyukov accepted D56159: [MSan] Handle llvm.is.constant intrinsic.

Nice! Interesting nobody reported this false positive on user-space code.

Dec 30 2018, 6:03 AM

Dec 22 2018

dvyukov accepted D55959: [TSan] Enable detection of lock-order-inversions for Objective-C @synchronized.

I would like to land this and fix @synchronized with tagged pointers in a follow-up since more discussion is required what we actually want it to do.

Dec 22 2018, 12:01 AM · Restricted Project

Dec 21 2018

dvyukov accepted D55075: [TSan] Remove ignore_interceptors_accesses flag.
Dec 21 2018, 11:44 PM · Restricted Project

Dec 20 2018

dvyukov added inline comments to D55075: [TSan] Remove ignore_interceptors_accesses flag.
Dec 20 2018, 10:21 PM · Restricted Project
dvyukov added inline comments to D55959: [TSan] Enable detection of lock-order-inversions for Objective-C @synchronized.
Dec 20 2018, 10:15 PM · Restricted Project

Dec 19 2018

dvyukov committed rCRT349609: tsan: align default value of detect_deadlocks flag with actual behavior.
tsan: align default value of detect_deadlocks flag with actual behavior
Dec 19 2018, 1:38 AM
dvyukov committed rL349609: tsan: align default value of detect_deadlocks flag with actual behavior.
tsan: align default value of detect_deadlocks flag with actual behavior
Dec 19 2018, 1:38 AM
dvyukov closed D55846: [TSan] Align default value of `detect_deadlocks` flag with actual behavior.

Merged as 349609.

Dec 19 2018, 1:38 AM · Restricted Project
dvyukov accepted D55846: [TSan] Align default value of `detect_deadlocks` flag with actual behavior.

Thanks!
Merging this now.

Dec 19 2018, 1:36 AM · Restricted Project

Dec 18 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR, here is current code:

Dec 18 2018, 8:02 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I added default synchronization and flag to opt-out.

Dec 18 2018, 7:36 AM · Restricted Project, Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 18 2018, 7:32 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I don't completely follow logic behind cur_thread/cur_thread_fast/cur_thread1 and how it does not introduce slowdown.
cur_thread_fast still includes an indirection, so it looks exactly the same as the first version.
cur_thread_fast does not check for NULL, so I would expect it to be used only in few carefully chosen functions. But it's used in most entry functions. Which makes me wonder: when cur_thread_fast cannot be used if it can be used in all these places?
It seems that you use cur_thread only to lazily initialize cur_thread1 in Initialize or ThreadStart. But then the question is: why don't we explicitly intialize cur_thread1 in these functions, and then just have a single cur_thread function as before with no 2 subtly different accessors?

Dec 18 2018, 7:26 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Can't agree with this. Only fiber is visible to user. Of cause, it is the same as thread until user switches it.

Dec 18 2018, 7:22 AM · Restricted Project, Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 18 2018, 7:18 AM · Restricted Project, Restricted Project

Dec 12 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Lingfeng, thanks for extensive feedback.

This should allow that logic to work for QEMU at least, and it feels like it should work for all possible other uses (?)

I am not sure there are no programs that use setjmp/longjmp to switch fibers across threads. Yes, man says behavior is undefined. But strictly saying, longjmp shouldn't be used for fiber switching too (it's solely for jumping upwards on the same stack). So I feel people are just relying on implementation details here (let's test it, works, ok, let's use it).

You said that QEMU uses sigsetjmp/siglongjmp for coroutine switches. How does a coroutine always stay on the same thread then? Say, if they have a thread pool servicing all coroutines, I would expect that coroutines are randomly intermixed across threads. So it can happen that we setjmp on one thread, but then reschedule the coroutine with longjmp on another thread.

Thanks for pointing that out. I have to check more closely, but I haven't observed migration of fibers across physical threads at all in qemu. The tendency is to both create and switch the coroutine on a dedicated thread. Swapcontext is done to a trampoline function, to which one can return again later on. Kind of like a fiber pool, where reuse of a fiber means longjmping to the trampoline instead of another swapcontext.

I don't think there is a thread pool that mixes around the fibers. I guess this means we would have to annotate in the more general use case, but for QEMU, if we make the assumption that setjmp/longjmp follow the spec, while only allowing for physical thread switches in swapcontext, we should be OK (And physical thread switching in swapcontext is somethign QEMU does not do).

Dec 12 2018, 2:54 AM · Restricted Project, Restricted Project

Dec 11 2018

dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 11 2018, 6:28 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Thinking of how we can eliminate the indirection in cur_thread...

Dec 11 2018, 6:10 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
Dec 11 2018, 5:17 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
  1. This introduces slowdown into the hottest runtime functions (branch and indirection in cur_thread). I think check_analyze.sh test will fail. Kinda hard to say, because it's broken already at the moment, but this perturbs runtime functions enough:

I have checked parts of the patch separately and found:

  • Part of patch related to HACKY_CALL does not affect code of critical functions and benchmark results
  • Part of patch related to proc() does not affect code of critical functions and benchmark results
  • The only part that affects critical functions is implementation cur_thread(). I tried to minimize its effect in new version of a patch.
Dec 11 2018, 5:02 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Hi Dmitry,
I will try to answer your questions

  1. Do we want to synchronize fibers on switch? If fibers use TLS data, or cooperative scheduling (e.g. mutex unlock directly schedules the next critical section owner), or pass some data from prev fiber to next fiber, in all these cases not synchronizing fibers on switch will lead to false positives. As far as I remember in my old experiments I concluded that it's almost impossible to get rid of false positives it tasks/fibers are not synchronized on switch.

In case of single-threaded scheduler, it is worth to synchronize fibers on each switch. Currently I do it in client code using _tsan_release()/_tsan_acquire(), but it is possible to add flag for _tsan_switch_to_fiber() that will do it.

In case of multithreaded scheduler, client probably has own sychronization primitives (for example, custom mutex), and it is client's responsibility to call corresponding TSAN functions.

Dec 11 2018, 4:40 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Lingfeng, thanks for extensive feedback.

Dec 11 2018, 4:31 AM · Restricted Project, Restricted Project

Dec 10 2018

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR, Lingfeng did prototype change to qemu that uses these annotations:
https://android-review.googlesource.com/c/platform/external/qemu/+/844675

Dec 10 2018, 8:18 AM · Restricted Project, Restricted Project
dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 10 2018, 5:05 AM · Restricted Project, Restricted Project

Dec 3 2018

dvyukov added inline comments to D54889: Fiber support for thread sanitizer.
Dec 3 2018, 8:24 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Some high-level comments:

  1. Do we want to synchronize fibers on switch? If fibers use TLS data, or cooperative scheduling (e.g. mutex unlock directly schedules the next critical section owner), or pass some data from prev fiber to next fiber, in all these cases not synchronizing fibers on switch will lead to false positives. As far as I remember in my old experiments I concluded that it's almost impossible to get rid of false positives it tasks/fibers are not synchronized on switch.
Dec 3 2018, 8:17 AM · Restricted Project, Restricted Project