Peter Zijlstra 2f7e3eac5f seqlock/latch: Provide raw_read_seqcount_latch_retry() ... [ Upstream commit d16317de9b ] The read side of seqcount_latch consists of: do { seq = raw_read_seqcount_latch(&latch->seq); ... } while (read_seqcount_latch_retry(&latch->seq, seq)); which is asymmetric in the raw_ department, and sure enough, read_seqcount_latch_retry() includes (explicit) instrumentation where raw_read_seqcount_latch() does not. This inconsistency becomes a problem when trying to use it from noinstr code. As such, fix it by renaming and re-implementing raw_read_seqcount_latch_retry() without the instrumentation. Specifically the instrumentation in question is kcsan_atomic_next(0) in do___read_seqcount_retry(). Loosing this annotation is not a problem because raw_read_seqcount_latch() does not pass through kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX). Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Michael Kelley <mikelley@microsoft.com> # Hyper-V Link: https://lore.kernel.org/r/20230519102715.233598176@infradead.org Stable-dep-of: 5c1806c41c ("kcsan, seqlock: Support seqcount_latch_t") Signed-off-by: Sasha Levin <sashal@kernel.org>		2024-12-14 19:50:46 +01:00
..
braille.c
braille.h
console_cmdline.h
index.c
internal.h
Makefile
printk_ringbuffer.c
printk_ringbuffer.h
printk_safe.c
printk.c	seqlock/latch: Provide raw_read_seqcount_latch_retry()	2024-12-14 19:50:46 +01:00