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.
114 .. _"Marking Shared-Memory Accesses" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/t…
128   accesses are aligned writes up to word size.
190 In an execution, two memory accesses form a *data race* if they *conflict*,
194 Accesses and Data Races" in the LKMM`_.
196 .. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/to…
236 KCSAN relies on observing that two accesses happen concurrently. Crucially, we
243 address set up, and then observe the watchpoint to fire, two accesses to the
253 compiler instrumenting plain accesses. For each instrumented plain access:
264 To detect data races between plain and marked accesses, KCSAN also annotates
265 marked accesses, but only to check if a watchpoint exists; i.e. KCSAN never
266 sets up a watchpoint on marked accesses. By never setting up watchpoints for
267 marked operations, if all accesses to a variable that is accessed concurrently
269 report the accesses.
303 concurrent accesses: because ``T2`` is able to proceed after the write of
311 the effects of "buffering" (delaying accesses), since the runtime cannot
312 "prefetch" accesses. Also recall that watchpoints are only set up for plain
313 accesses, and the only access type for which KCSAN simulates reordering. This
314 means reordering of marked accesses is not modeled.
317 instrumentation (no prefetching). Furthermore, marked accesses introducing
319 access cannot be reordered, later dependent accesses cannot be prefetched).