Reading /sys/kernel/debug/kcsan returns various runtime statistics. The file /sys/kernel/debug/kcsan provides the following interface: To use the strictest possible rules, select CONFIG_KCSAN_STRICT=y, whichĬonfigures KCSAN to follow the Linux-kernel memory consistency model (LKMM) as Only focus on reports from specific subsystems and not the whole kernel are Please see the kernel/kcsan/permissive.h.
Option depends on CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=y. Unlike the above, the rules are moreĬomplex involving value-change patterns, access type, and address. The optionĬauses KCSAN to not report data races due to conflicts where the only plainĪccesses are aligned writes up to word size.ĬONFIG_KCSAN_PERMISSIVE: Enable additional permissive rules to ignoreĬertain classes of common data races. Subject to unsafe compiler optimizations resulting in data races. Observed to remain unchanged, do not report the data race.ĬONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC: Assume that plain aligned writes Is observed via a watchpoint, but the data value of the memory location was These can be changed via the followingĬONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY: If enabled and a conflicting write "Marking Shared-Memory Accesses" in the LKMM for more information.ĭisabling data race detection for entire functions can be accomplished byįurthermore, it is possible to tell KCSAN to show or hide entire classes ofĭata races, depending on preferences. KCSAN understands the data_race(expr) annotation, which tells KCSAN thatĪny data races due to accesses in expr should be ignored and resultingīehaviour when encountering a data race is deemed safe. It may be desirable to disable data race detection for specific accesses,įunctions, compilation units, or entire subsystems. Such reportsĪre shown only if CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y, which is The racing thread, but could also occur due to e.g. A common reason for reports of this type are missing instrumentation in These reports always show a "value changed" Racing thread, but a race was inferred due to the data value of the watched This report is generated where it was not possible to determine the other Race at unknown origin, with read to 0xffffffffc009bdb0 of 8 bytes by task 515 on cpu 2: The other less common type of data race report looks like this:īUG: KCSAN: data-race in test_kernel_rmw_array+0x71/0xd0 Old value and new value are shown on the "value changed" line respectively. If KCSAN also observed a value change, the observed It is followed by the access types and stack traces of the 2 threads
The header of the report provides a short summary of the functions involved in
#LINUX KERNEL DOCUMENTATION PC#
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 Reported by Kernel Concurrency Sanitizer on:ĬPU: 6 PID: 488 Comm: access_thread Not tainted 5.12.0-rc2+ #1 Read to 0xffffffffc009a628 of 8 bytes by task 488 on cpu 6: Write to 0xffffffffc009a628 of 8 bytes by task 487 on cpu 0: BUG: KCSAN: data-race in test_kernel_read / test_kernel_write
0 kommentar(er)
