This is an archive of the discontinued LLVM Phabricator instance.

added reset feature to dfsan
Needs ReviewPublic

Authored by farahhariri on Jul 20 2017, 3:47 PM.

Details

Reviewers
kcc
pcc
Summary

Adding reset feature to dfsan. This is especially needed in the context of fuzzing. Otherwise, we would run out of labels very fast.

Event Timeline

farahhariri created this revision.Jul 20 2017, 3:47 PM
kcc edited edge metadata.Jul 24 2017, 11:42 AM

also, would like to hear from @pcc

include/sanitizer/dfsan_interface.h
55

Explain thread-[un]safety
I assume this function is *not* thread safe and thus the comment must be clear on this topic.
Add '.' at the end

lib/dfsan/dfsan.cc
180

Add some code to check-fail in case __dfsan_last_label has changed (i.e. to check that no other threads are messing around)

Then, add a test with threads that will trigger that check-fail.

pcc added inline comments.Jul 24 2017, 2:49 PM
include/sanitizer/dfsan_interface.h
55

Please also document that there should also be no active stack frames which may be processing values with non-zero labels.

test/dfsan/reset.cc
19

Is this safe, given the constraint I mentioned above? I'd prefer to move the code that creates labels into a separate function.

farahhariri added inline comments.Jul 26 2017, 3:27 PM
lib/dfsan/dfsan.cc
180

Then, add a test with threads that will trigger that check-fail.

That means I will have to add a flaky test that sometimes passes and sometimes fails.
I cannot guarantee that the scheduler will switch context between the atomic store and
the check-fail to another thread, and then switch back to the check-fail. That's the only
way to guarantee it will fail..

kcc added inline comments.Jul 26 2017, 3:33 PM
lib/dfsan/dfsan.cc
180

You can create a test that runs a very long loop in a thread and thus guarantee that the test will crash 9999999999999999 our of 100000000000000 times.

addressed concerns related to multithreaded code

farahhariri marked 3 inline comments as done.Jul 28 2017, 11:22 AM
farahhariri added inline comments.
lib/dfsan/dfsan.cc
180

I tried that and let it run for 12+ hours and could not trigger the assertion after the atomic store to fail. But what I did is control the thread scheduling from the test and make an assertion in that test fail (check the update).

pcc added inline comments.Jul 31 2017, 5:04 PM
lib/dfsan/dfsan.cc
175

Is this part necessary? I believe that the mmap call above will also reset the union table to zero.

test/dfsan/reset_multithread.cc
21

Is this really testing for the property that Kostya mentioned? It seems like it is trying to reproduce the scenario where the labels are created in the other thread *after* (i.e. not parallel with) the reset. You might have better luck reproducing if you change the dfsan_reset function to do this:

void dfsan_reset() {
  atomic store to dfsan_last_label;
  mmap;
  assert(atomic load from dfan_last_label == 0);
}

removed unecessary reset, and fixed multithreaded test.

farahhariri marked 2 inline comments as done.Aug 1 2017, 12:59 PM
farahhariri added inline comments.
lib/dfsan/dfsan.cc
175

You're right it's not. Thanks!

farahhariri marked 6 inline comments as done.
This comment was removed by farahhariri.
pcc edited edge metadata.Aug 8 2017, 10:51 AM

Please add the other hooks in a separate patch.

test/dfsan/reset_multithread.cc
20

Is this assert necessary? It's basically testing for the same thing as the assert in dfsan_reset, isn't it?

This comment was removed by farahhariri.