- User Since
- Dec 6 2012, 2:31 AM (411 w, 1 d)
Thu, Oct 1
Wed, Sep 30
We are querying own PID, I don't understand how it can be wrong. We definitely did not kill itself if we are still running :)
Please add a test that exposes the problem. Will also help to understand what scenario we are fixing.
Aug 13 2020
Aug 7 2020
Jul 30 2020
Jul 24 2020
Jul 20 2020
Jul 16 2020
In practice, it probably doesn't really matter because T0 would probably load acquire spin on B or something better, and it'd be all in separate basic blocks.
LGTM on my side
What would be an example of code where it matters?
No idea why it broke now. THe change to tsan_test_util_posix.cpp looks fine to me.
Jul 15 2020
Alex, is this still relevant? If not, please close.
Looks good to me.
You have access, right? If so, please land it.
Jul 14 2020
Jun 8 2020
May 28 2020
May 27 2020
May 25 2020
My one concern is that the change revives the last_acquire_ optimization while still allowing vector clocks to reflect non-linearizable global states.
May 24 2020
May 23 2020
Daniel, I am not asking to review (but if you want, you are welcome!). It's just a very interesting exercise in vector clock reasoning and a super tricky bug, so I thought you may be interested.
May 15 2020
Maybe this flag should turn off instrumentation of the "atomic" writes? Then the "reads-before-write" are not before writes anymore and will be naturally instrumented. And we also get faster execution. What do you think?
Apr 22 2020
ninja check-tsan passed.
ninja check-all kills my self-isolation machine, so let's assume it works...
committed as: https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
Apr 21 2020
Any objections, anybody?
I am not opposed to adding this in general. Andrey did the same for KTSAN in gcc long time ago.
However, this feature will be present only in the newest clang and not in gcc. So what is the use story for kernel? Do we make KCSAN require the newest clang? I think majority of kernel developers use gcc.
Apr 16 2020
You can now land this yourself, right?
Apr 14 2020
Please add a unit test for these bugs to tsan/tests/unit/tsan_clock_test.cpp and releaseStoreAcquire to the stress test in that file.
Apr 11 2020
Apr 10 2020
Apr 9 2020
Apr 7 2020
This is lots of changes. This makes me nervous and makes it harder for me approve this. Tsan is currently in maintenance mode with no official staffing and I don't remember most of this code well. Keeping changes "safer" makes it much easier to handle.
Say, you reorder thr->~ThreadState() and StatAggregate. And this has no explanation and is hidden in the code movement, so not even really visible. This makes me wonder why, and if you have given this enough consideration and are there other similar hidden changes...
Also moving all this ThreadSignalContext/SignalDesc/ucontext_buffer_t/768/129/65 into abstract logic layer makes me wince. It was specifically kept as "interceptors" stuff for a 8 years. I think the same can be achieved by providing a callback in tsan_interceptors_posix.cc with no major code movement.
If you restrict this to just fixing the bug, it will make both of us less scared of breaking things :)
Refactrorings may go in separate subsequent changes with own proper descriptions. This is much better for review, tests and these are also a unit of rollback. So if just a refactoring is rolled back, that's much better.
Apr 2 2020
Apr 1 2020
Mar 31 2020
Mar 28 2020
Mar 26 2020
What was the failure?
Mar 25 2020
Should we take this bigger discussion on refactoring to the mailing list and keep this review to fixing the leak?
So essentially in Go a ThreadState is used as a Fiber (which they call goroutine and schedule internally)?
Maybe it would be beneficial to do the same for the thread state?
Would it be a worthwhile effort for me to pull responsibilities of logical and 'real' threads apart?
Lastly, if I plan to make changes, is it ok to introduce features like virtual classes and smart pointers (on non hot paths) or are there restrictions on these in the codebase?
Mar 24 2020
Mar 21 2020
Mar 20 2020
I would appreciate feedback if this way of fixing the leak is ok.
Mar 19 2020
Overall looks good, which some nits.
Mar 10 2020
How did you test this?
Mar 9 2020
Mar 8 2020
Interesting difference between C and C++...
Do you want me to merge this as well? or you have commit access?
Feb 26 2020
changed warning checking in test
Feb 24 2020