Changes in kcsan_test.c

8fa7292f - treewide: Switch/rename to timer_delete[_sync]()

Sat, 05 Apr 2025 08:17:26 +0000

treewide: Switch/rename to timer_delete[_sync]()timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole treeover and remove the historical wrapper inlines.Conversion was done with coccinelle plus manual fixups where necessary.Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

ddd7432d - kcsan: Add missing MODULE_DESCRIPTION() macro

Thu, 30 May 2024 19:39:26 +0000

kcsan: Add missing MODULE_DESCRIPTION() macroFix the warning reported by 'make C=1 W=1':WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/kcsan/kcsan_test.oSigned-off-by: Jeff Johnson Reviewed-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

31f605a3 - kcsan, compiler_types: Introduce __data_racy type qualifier

Thu, 02 May 2024 14:12:17 +0000

kcsan, compiler_types: Introduce __data_racy type qualifierBased on the discussion at [1], it would be helpful to mark certainvariables as explicitly "data racy", which would result in KCSAN notreporting data races involving any accesses on such variables. To dothat, introduce the __data_racy type qualifier: struct foo { ... int __data_racy bar; ... };In KCSAN-kernels, __data_racy turns into volatile, which KCSAN alreadytreats specially by considering them "marked". In non-KCSAN kernels thetype qualifier turns into no-op.The generated code between KCSAN-instrumented kernels and non-KCSANkernels is already huge (inserted calls into runtime for every memoryaccess), so the extra generated code (if any) due to volatile for fewsuch __data_racy variables are unlikely to have measurable impact onperformance.Link: https://lore.kernel.org/all/CAHk-=wi3iondeh_9V2g3Qz5oHTRjLsOpoy83hb58MVh=nRZe0A@mail.gmail.com/ [1]Suggested-by: Linus Torvalds Signed-off-by: Marco Elver Cc: Paul E. McKenney Cc: Tetsuo Handa Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

f12fb73b - mm: delete checks for xor_unlock_is_negative_byte()

Wed, 04 Oct 2023 16:53:14 +0000

mm: delete checks for xor_unlock_is_negative_byte()Architectures which don't define their own use the one inasm-generic/bitops/lock.h. Get rid of all the ifdefs around "maybe wedon't have it".Link: https://lkml.kernel.org/r/20231004165317.1061855-15-willy@infradead.orgSigned-off-by: Matthew Wilcox (Oracle) Acked-by: Geert Uytterhoeven Cc: Albert Ou Cc: Alexander Gordeev Cc: Andreas Dilger Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Heiko Carstens Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Richard Henderson Cc: Sven Schnelle Cc: "Theodore Ts'o" Cc: Thomas Bogendoerfer Cc: Vasily Gorbik Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

247dbcdb - bitops: add xor_unlock_is_negative_byte()

Wed, 04 Oct 2023 16:53:07 +0000

bitops: add xor_unlock_is_negative_byte()Replace clear_bit_and_unlock_is_negative_byte() withxor_unlock_is_negative_byte(). We have a few places that like to lock afolio, set a flag and unlock it again. Allow for the possibility ofcombining the latter two operations for efficiency. We are guaranteedthat the caller holds the lock, so it is safe to unlock it with the xor. The caller must guarantee that nobody else will set the flag withoutholding the lock; it is not safe to do this with the PG_dirty flag, forexample.Link: https://lkml.kernel.org/r/20231004165317.1061855-8-willy@infradead.orgSigned-off-by: Matthew Wilcox (Oracle) Cc: Albert Ou Cc: Alexander Gordeev Cc: Andreas Dilger Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Geert Uytterhoeven Cc: Heiko Carstens Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Richard Henderson Cc: Sven Schnelle Cc: "Theodore Ts'o" Cc: Thomas Bogendoerfer Cc: Vasily Gorbik Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

1f6ab566 - printk: export console trace point for kcsan/kasan/kfence/kmsan

Thu, 13 Apr 2023 10:08:59 +0000

printk: export console trace point for kcsan/kasan/kfence/kmsanThe console tracepoint is used by kcsan/kasan/kfence/kmsan test modules. Since this tracepoint is not exported, these modules iterate over allavailable tracepoints to find the console trace point. Export the tracepoint so that it can be directly used.Link: https://lkml.kernel.org/r/20230413100859.1492323-1-quic_pkondeti@quicinc.comSigned-off-by: Pavankumar Kondeti Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: John Ogness Cc: Marco Elver Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: Vincenzo Frascino Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

5b24ac2d - kcsan: test: don't put the expect array on the stack

Fri, 23 Dec 2022 07:28:21 +0000

kcsan: test: don't put the expect array on the stackSize of the 'expect' array in the __report_matches is 1536 bytes, whichis exactly the default frame size warning limit of the xtensaarchitecture.As a result allmodconfig xtensa kernel builds with the gcc that does notsupport the compiler plugins (which otherwise would push the saidwarning limit to 2K) fail with the following message: kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytesFix it by dynamically allocating the 'expect' array.Signed-off-by: Max Filippov Reviewed-by: Marco Elver Tested-by: Marco Elver List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

2434031c - kcsan: test: use new suite_{init,exit} support

Wed, 04 May 2022 07:09:41 +0000

kcsan: test: use new suite_{init,exit} supportUse the newly added suite_{init,exit} support for suite-wide init andcleanup. This avoids the unsupported method by which the test used to dosuite-wide init and cleanup (avoiding issues such as missing TAPheaders, and possible future conflicts).Signed-off-by: Marco Elver Signed-off-by: Shuah Khan List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

5693fa74 - kcsan: Use preemption model accessors

Fri, 12 Nov 2021 18:52:02 +0000

kcsan: Use preemption model accessorsPer PREEMPT_DYNAMIC, checking CONFIG_PREEMPT doesn't tell you the actualpreemption model of the live kernel. Use the newly-introduced accessorsinstead.Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Marco Elver Acked-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20211112185203.280040-4-valentin.schneider@arm.com List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

b473a389 - kcsan: Only test clear_bit_unlock_is_negative_byte if arch defines it

Mon, 06 Dec 2021 06:41:51 +0000

kcsan: Only test clear_bit_unlock_is_negative_byte if arch defines itSome architectures do not define clear_bit_unlock_is_negative_byte().Only test it when it is actually defined (similar to other usage, suchas in lib/test_kasan.c).Link: https://lkml.kernel.org/r/202112050757.x67rHnFU-lkp@intel.comReported-by: kernel test robot Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

a70d36e6 - kcsan: Make barrier tests compatible with lockdep

Fri, 03 Dec 2021 23:38:17 +0000

kcsan: Make barrier tests compatible with lockdepThe barrier tests in selftest and the kcsan_test module only need thespinlock and mutex to test correct barrier instrumentation. Therefore,these were initially placed on the stack.However, lockdep asserts that locks are in static storage, and willgenerate this warning: | INFO: trying to register non-static key. | The code is fine but needs lockdep annotation, or maybe | you didn't initialize this object before use? | turning off the locking correctness validator. | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.16.0-rc1+ #3208 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 | Call Trace: | | dump_stack_lvl+0x88/0xd8 | dump_stack+0x15/0x1b | register_lock_class+0x6b3/0x840 | ... | test_barrier+0x490/0x14c7 | kcsan_selftest+0x47/0xa0 | ...To fix, move the test locks into static storage.Fixing the above also revealed that lock operations are strengthened onfirst use with lockdep enabled, due to lockdep calling out intonon-instrumented files (recall that kernel/locking/lockdep.c is notinstrumented with KCSAN).Only kcsan_test checks for over-instrumentation of *_lock() operations,where we can simply "warm up" the test locks to avoid the test casefailing with lockdep.Reported-by: Paul E. McKenney Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

8bc32b34 - kcsan: test: Add test cases for memory barrier instrumentation

Tue, 30 Nov 2021 11:44:19 +0000

kcsan: test: Add test cases for memory barrier instrumentationAdds test cases to check that memory barriers are instrumentedcorrectly, and detection of missing memory barriers is working asintended if CONFIG_KCSAN_STRICT=y.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

7310bd1f - kcsan: test: Match reordered or normal accesses

Tue, 30 Nov 2021 11:44:18 +0000

kcsan: test: Match reordered or normal accessesDue to reordering accesses with weak memory modeling, any access can nowappear as "(reordered)".Match any permutation of accesses if CONFIG_KCSAN_WEAK_MEMORY=y, so thatwe effectively match an access if it is denoted "(reordered)" or not.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

3cc21a53 - kcsan: Call scoped accesses reordered in reports

Tue, 30 Nov 2021 11:44:15 +0000

kcsan: Call scoped accesses reordered in reportsThe scoping of an access simply denotes the scope in which it may bereordered. However, in reports, it'll be less confusing to say theaccess is "reordered". This is more accurate when the race occurred.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

d627c537 - kcsan: Support reporting scoped read-write access type

Mon, 09 Aug 2021 11:25:15 +0000

kcsan: Support reporting scoped read-write access typeSupport generating the string representation of scoped read-writeaccesses for completeness. They will become required in planned changes.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

6c65eb75 - kcsan: Start stack trace with explicit location if provided

Mon, 09 Aug 2021 11:25:14 +0000

kcsan: Start stack trace with explicit location if providedIf an explicit access address is set, as is done for scoped accesses,always start the stack trace from that location. get_stack_skipnr() ischanged into sanitize_stack_entries(), which if given an address, scansthe stack trace for a matching function and then replaces that entrywith the explicitly provided address.The previous reports for scoped accesses were all over the place, whichcould be quite confusing. We now always point at the start of the scope.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

ade3a58b - kcsan: test: Fix flaky test case

Mon, 09 Aug 2021 11:25:11 +0000

kcsan: test: Fix flaky test caseIf CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=n, then we may also see dataraces between the writers only. If we get unlucky and never capture aread-write data race, but only the write-write data races, then thetest_no_value_change* test cases may incorrectly fail.The second problem is that the initial value needs to be reset, asotherwise we might actually observe a value change at the start.Fix it by also looking for the write-write data races, and resetting thevalue to what will be written.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

80804284 - kcsan: test: Use kunit_skip() to skip tests

Mon, 09 Aug 2021 11:25:10 +0000

kcsan: test: Use kunit_skip() to skip testsUse the new kunit_skip() to skip tests if requirements were not met.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

e8070427 - kcsan: test: Defer kcsan_test_init() after kunit initialization

Mon, 09 Aug 2021 11:25:09 +0000

kcsan: test: Defer kcsan_test_init() after kunit initializationWhen the test is built into the kernel (not a module), kcsan_test_init()and kunit_init() both use late_initcall(), which means kcsan_test_init()might see a NULL debugfs_rootdir as parent dentry, resulting inkcsan_test_init() and kcsan_debugfs_init() both trying to create adebugfs node named "kcsan" in debugfs root. One of them will show anerror and be unsuccessful.Defer kcsan_test_init() until we're sure kunit was initialized.Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c

d8fd74d3 - kcsan: permissive: Ignore data-racy 1-bit value changes

Mon, 07 Jun 2021 12:56:53 +0000

kcsan: permissive: Ignore data-racy 1-bit value changesAdd rules to ignore data-racy reads with only 1-bit value changes.Details about the rules are captured in comments inkernel/kcsan/permissive.h. More background follows.While investigating a number of data races, we've encountered data-racyaccesses on flags variables to be very common. The typical pattern is areader masking all but one bit, and/or the writer setting/clearing only1 bit (current->flags being a frequently encountered case; more examplesin mm/sl[au]b.c, which disable KCSAN for this reason).Since these types of data-racy accesses are common (with the assumptionthey are intentional and hard to miscompile) having the option (withCONFIG_KCSAN_PERMISSIVE=y) to filter them will avoid forcing everyone tomark them, and deliberately left to preference at this time.One important motivation for having this option built-in is to movecloser to being able to enable KCSAN on CI systems or for testerswishing to test the whole kernel, while more easily filteringless interesting data races with higher probability.For the implementation, we considered several alternatives, but had onemajor requirement: that the rules be kept together with the Linux-kerneltree. Adding them to the compiler would preclude us from making changesquickly; if the rules require tweaks, having them part of the compilerrequires waiting another ~1 year for the next release -- that's notrealistic. We are left with the following options: 1. Maintain compiler plugins as part of the kernel-tree that removes instrumentation for some accesses (e.g. plain-& with 1-bit mask). The analysis would be reader-side focused, as no assumption can be made about racing writers.Because it seems unrealistic to maintain 2 plugins, one for LLVM andGCC, we would likely pick LLVM. Furthermore, no kernel infrastructureexists to maintain LLVM plugins, and the build-system implications andmaintenance overheads do not look great (historically, plugins writtenagainst old LLVM APIs are not guaranteed to work with newer LLVM APIs). 2. Find a set of rules that can be expressed in terms of observed value changes, and make it part of the KCSAN runtime. The analysis is writer-side focused, given we rely on observed value changes.The approach taken here is (2). While a complete approach requires both(1) and (2), experiments show that the majority of data races involvingtrivial bit operations on flags variables can be removed with (2) alone.It goes without saying that the filtering of data races using (1) or (2)does _not_ guarantee they are safe! Therefore, limiting ourselves to (2)for now is the conservative choice for setups that wish to enableCONFIG_KCSAN_PERMISSIVE=y.Signed-off-by: Marco Elver Acked-by: Mark Rutland Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/kcsan/kcsan_test.c