Lines Matching full:accesses

78 the racing thread, but could also occur due to e.g. DMA accesses. Such reports
85 It may be desirable to disable data race detection for specific accesses,
90   any data races due to accesses in ``expr`` should be ignored and resulting
92   `"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
95   to document that all data races due to accesses to a variable are intended
124 .. _"Marking Shared-Memory Accesses" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/t…
138   accesses are aligned writes up to word size.
200 In an execution, two memory accesses form a *data race* if they *conflict*,
204 Accesses and Data Races" in the LKMM`_.
206 .. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/to…
246 KCSAN relies on observing that two accesses happen concurrently. Crucially, we
253 address set up, and then observe the watchpoint to fire, two accesses to the
263 compiler instrumenting plain accesses. For each instrumented plain access:
274 To detect data races between plain and marked accesses, KCSAN also annotates
275 marked accesses, but only to check if a watchpoint exists; i.e. KCSAN never
276 sets up a watchpoint on marked accesses. By never setting up watchpoints for
277 marked operations, if all accesses to a variable that is accessed concurrently
279 report the accesses.
313 concurrent accesses: because ``T2`` is able to proceed after the write of
321 the effects of "buffering" (delaying accesses), since the runtime cannot
322 "prefetch" accesses. Also recall that watchpoints are only set up for plain
323 accesses, and the only access type for which KCSAN simulates reordering. This
324 means reordering of marked accesses is not modeled.
327 instrumentation (no prefetching). Furthermore, marked accesses introducing
329 access cannot be reordered, later dependent accesses cannot be prefetched).