On Tue, Jul 21, 2020 at 04:05PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 21, 2020 at 12:30:11PM +0200, Marco Elver wrote:
> > For compound instrumentation and assert accesses, skew the watchpoint
> > delay to be longer. We still shouldn't exceed the maximum delays, but it
> > is safe to skew the delay for these accesses.
>
> Complete lack of actual justification.. *why* are you doing this, and
> *why* is it safe etc..
CONFIG_KCSAN_UDELAY_{TASK,INTERRUPT} define the upper bound. When
randomized, the delays aggregate around a mean of KCSAN_UDELAY/2. We're
not breaking the promise of not exceeding the max by skewing the delay
if randomized. That's all this was meant to say.
I'll rewrite the commit message:
For compound instrumentation and assert accesses, skew the
watchpoint delay to be longer if randomized. This is useful to
improve race detection for such accesses.
For compound accesses we should increase the delay as we've
aggregated both read and write instrumentation. By giving up 1
call into the runtime, we're less likely to set up a watchpoint
and thus less likely to detect a race. We can balance this by
increasing the watchpoint delay.
For assert accesses, we know these are of increased interest,
and we wish to increase our chances of detecting races for such
checks.
Note that, CONFIG_KCSAN_UDELAY_{TASK,INTERRUPT} define the upper
bound delays. Skewing the delay does not break this promise as
long as the defined upper bounds are still adhered to.
Thanks,
-- Marco
