Lines Matching +full:hardware +full:- +full:wise
1 MARKING SHARED-MEMORY ACCESSES
6 not use read-modify-write atomic operations. It also describes how to
13 ACCESS-MARKING OPTIONS
16 The Linux kernel provides the following access-marking options:
18 1. Plain C-language accesses (unmarked), for example, "a = b;"
20 2. Data-race marking, for example, "data_race(a = b);"
30 6. KCSAN's negative-marking assertions, ASSERT_EXCLUSIVE_ACCESS()
32 "ACCESS-DOCUMENTATION OPTIONS" section below.
39 Neither plain C-language accesses nor data_race() (#1 and #2 above) place
42 compiler's use of code-motion and common-subexpression optimizations.
46 C-language accesses. It is permissible to combine #2 and #3, for example,
51 C-language accesses, but marking all accesses involved in a given data
56 ill-considered additions of data_race(), READ_ONCE(), and WRITE_ONCE()
60 data_race() and even plain C-language accesses is preferable to
65 ----------------------------
70 1. Data-racy loads from shared variables whose values are used only
73 2. Data-racy reads whose values are checked against marked reload.
75 3. Reads whose values feed into error-tolerant heuristics.
77 4. Writes setting values that feed into error-tolerant heuristics.
80 Data-Racy Reads for Approximate Diagnostics
90 prevents any non-diagnostic reads from shared variable x from running
91 concurrently with updates to x. Then using plain C-language writes
95 false-positive warnings about these diagnostic reads.
101 In theory, plain C-language loads can also be used for this use case.
107 Data-Racy Reads That Are Checked Against Marked Reload
125 In theory, plain C-language loads can also be used for this use case.
131 Reads Feeding Into Error-Tolerant Heuristics
146 In theory, plain C-language loads can also be used for this use case.
152 Writes Setting Values Feeding Into Error-Tolerant Heuristics
154 The values read into error-tolerant heuristics come from somewhere,
158 due to compiler-mangled reads, it can also tolerate the occasional
159 compiler-mangled write, at least assuming that the proper value is in
162 Plain C-language stores can also be used for this use case. However,
169 Use of Plain C-Language Accesses
170 --------------------------------
172 Here are some example situations where plain C-language accesses should
178 2. Initialization-time and cleanup-time accesses. This covers a
180 system boot, variables to be used by not-yet-spawned kthreads,
181 structures not yet published to reference-counted or RCU-protected
184 3. Per-CPU variables that are not accessed from other CPUs.
186 4. Private per-task variables, including on-stack variables, some
187 fields in the task_struct structure, and task-private heap data.
196 by default, refraining from flagging plain C-language stores:
209 Note that it is important to use plain C-language accesses in these cases,
215 ------------------
223 Note well that __data_racy is subject to the same pointer-declaration
227 int __data_racy *p; // Pointer to data-racy data.
228 int *__data_racy p; // Data-racy pointer to non-data-racy data.
231 ACCESS-DOCUMENTATION OPTIONS
236 However, it is even more important to comment plain C-language accesses
267 -----------------------------------------------
270 reader-writer spinlock is read-held, written only while that same
271 spinlock is write-held, except that it is also read locklessly for
301 The reader-writer lock prevents the compiler from introducing concurrency
304 should) be plain C-language accesses. One benefit of making them be
305 plain C-language accesses is that KCSAN can detect any erroneous lockless
332 running on the same CPU doing the legitimate lock-protected write, you
335 it is not necessarily a full replacement for hardware watchpoints.
336 On the other hand, neither are hardware watchpoints a full replacement
337 for KCSAN because it is not always easy to tell hardware watchpoint to
341 Lock-Protected Writes With Lockless Reads
342 -----------------------------------------
371 Lock-Protected Writes With Heuristic Lockless Reads
372 ---------------------------------------------------
375 a per-data-structure lock, but there are times when a global lock
395 spin_lock(&fp->f_lock);
398 spin_unlock(&fp->f_lock);
401 spin_unlock(&fp->f_lock);
405 spin_lock(&fp->f_lock);
409 * will wait for ->f_lock to be released.
412 spin_unlock(&fp->f_lock);
423 * Wait for pre-existing local locks. One at
426 spin_lock(&fp->f_lock);
427 spin_unlock(&fp->f_lock);
442 rechecked while holding ->f_lock, which, if global_flag is now false,
448 ->f_lock will prevent any call to begin_global() from returning, which
458 end_global() are carried out without holding that structure's ->f_lock.
465 -------------------------
490 flag any concurrent plain C-language reads from foo, and given
492 C-language writes to foo.
495 Lockless Reads and Writes, But With Single-Threaded Initialization
496 ------------------------------------------------------------------
499 single-threaded manner, but that a number of kthreads are then created
532 The initialize_foo() uses a plain C-language write to foo because there
540 Checking Stress-Test Race Coverage
541 ----------------------------------
606 If a given stress-test run does not result in KCSAN complaints from
609 on a regular basis, it would be wise to place the above instances of
617 [1] "Concurrency bugs should fear the big bad data-race detector (part 2)"
621 https://www.linuxfoundation.org/webinars/the-kernel-concurrency-sanitizer