On Mon, 29 Nov 2021 at 15:27, Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
[...]
> > This case is also possible:
> >
> > static int v;
> > static int x;
> > int foo(..)
> > {
> > ASSERT_EXCLUSIVE_ACCESS_SCOPED(v);
> > x++; // preempted during watchpoint for 'v' after checking x++
> > }
> >
> > Here, all we need is for the scoped access to be checked after x++, end
> > up with a watchpoint for it, then enter scheduler code, which then
> > checked 'v', sees the conflicting watchpoint, and reports a nonsensical
> > race again.
> >
>
> Just to be clear, in both examples, the assumption is that 'v' is a
> variable that scheduler code doesn't access, right? Because if scheduler
> code does access 'v', then it's a problem that KCSAN should report. Yes,
> I don't know any variable that scheduler exports, just to make sure
> here.
Right. We might miss such cases where an ASSERT_EXCLUSIVE*_SCOPED()
could have pointed out a legitimate race with a nested context that
share ctx, like in scheduler, where the only time to detect it is if
some state change later in the scope makes a concurrent access
possible from that point in the scope. I'm willing to bet that there's
an extremely small chance we'll ever encounter such a case (famous
last words ;-)), i.e. the initial check_access() in
kcsan_begin_scoped_access() wouldn't detect it nor would the problem
manifest as a regular data race.
Thanks,
-- Marco
