From: Marco Elver <elver@google.com>
To: elver@google.com
Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>,
Dmitry Vyukov <dvyukov@google.com>
Subject: [PATCH v2] kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()
Date: Wed, 22 Apr 2026 14:52:28 +0200 [thread overview]
Message-ID: <20260422125256.87513-1-elver@google.com> (raw)
Some subsystems enable -Wmaybe-uninitialized [1], which can trigger
false positives when KCSAN is enabled. Specifically, passing an
uninitialized variable to functions that instrument accesses (e.g.,
copy_from_user()) results in calls to __kcsan_check_access().
Because __kcsan_check_access() takes a `const volatile void *ptr`, GCC
infers that the function may only read the memory location, and thus
warns if the passed variable is uninitialized.
However, KCSAN is a dynamic analysis tool for data race detection; while
it does read the memory location to detect concurrent modifications, the
"initialized'ness" of the memory location is irrelevant for its analysis.
Use absolute_pointer() in __kcsan_check_write(), kcsan_check_write(),
and kcsan_check_atomic_write() to hide the pointer from the compiler,
preventing it from concluding that the pointer passed points to
uninitialized memory.
This fixes warnings like:
| CC fs/ntfs3/file.o
| In file included from include/asm-generic/rwonce.h:27,
| from arch/arm64/include/asm/rwonce.h:81,
| from include/linux/compiler.h:369,
| from include/linux/array_size.h:5,
| from include/linux/kernel.h:16,
| from include/linux/backing-dev.h:12,
| from fs/ntfs3/file.c:10:
| In function 'instrument_copy_from_user_before',
| inlined from '_inline_copy_from_user' at include/linux/uaccess.h:184:2,
| inlined from 'copy_from_user' at include/linux/uaccess.h:221:9,
| inlined from 'ntfs_ioctl_fitrim' at fs/ntfs3/file.c:77:6,
| inlined from 'ntfs_ioctl' at fs/ntfs3/file.c:164:10:
| include/linux/kcsan-checks.h:220:28: error: 'range' may be used uninitialized [-Werror=maybe-uninitialized]
| 220 | #define kcsan_check_access __kcsan_check_access
| | ^
| include/linux/kcsan-checks.h:311:9: note: in expansion of macro 'kcsan_check_access'
| 311 | kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE)
| | ^~~~~~~~~~~~~~~~~~
| include/linux/instrumented.h:147:9: note: in expansion of macro 'kcsan_check_write'
| 147 | kcsan_check_write(to, n);
| | ^~~~~~~~~~~~~~~~~
| include/linux/kcsan-checks.h: In function 'ntfs_ioctl':
| include/linux/kcsan-checks.h:37:6: note: by argument 1 of type 'const volatile void *' to '__kcsan_check_access' declared here
| 37 | void __kcsan_check_access(const volatile void *ptr, size_t size, int type);
| | ^~~~~~~~~~~~~~~~~~~~
| fs/ntfs3/file.c:65:29: note: 'range' declared here
| 65 | struct fstrim_range range;
| | ^~~~~
Link: https://lore.kernel.org/all/5da10cca-875b-418d-b54e-6be3ea32c266@app.fastmail.com/ [1]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marco Elver <elver@google.com>
---
v2:
* Switch from __attribute__((access)) to absolute_pointer() to silence
the warnings instead of introducing new ones.
---
include/linux/kcsan-checks.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h
index 92f3843d9ebb..e135dacaa90f 100644
--- a/include/linux/kcsan-checks.h
+++ b/include/linux/kcsan-checks.h
@@ -282,7 +282,7 @@ static inline void __kcsan_disable_current(void) { }
* @size: size of access
*/
#define __kcsan_check_write(ptr, size) \
- __kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE)
+ __kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_WRITE)
/**
* __kcsan_check_read_write - check regular read-write access for races
@@ -308,7 +308,7 @@ static inline void __kcsan_disable_current(void) { }
* @size: size of access
*/
#define kcsan_check_write(ptr, size) \
- kcsan_check_access(ptr, size, KCSAN_ACCESS_WRITE)
+ kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_WRITE)
/**
* kcsan_check_read_write - check regular read-write access for races
@@ -331,7 +331,7 @@ static inline void __kcsan_disable_current(void) { }
#define kcsan_check_atomic_read(ptr, size) \
kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC)
#define kcsan_check_atomic_write(ptr, size) \
- kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE)
+ kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE)
#define kcsan_check_atomic_read_write(ptr, size) \
kcsan_check_access(ptr, size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND)
#endif
--
2.54.0.rc2.533.g4f5dca5207-goog
next reply other threads:[~2026-04-22 12:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 12:52 Marco Elver [this message]
2026-04-30 13:30 ` [PATCH v2] kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access() Marco Elver
2026-04-30 13:35 ` Arnd Bergmann
2026-04-30 13:55 ` Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260422125256.87513-1-elver@google.com \
--to=elver@google.com \
--cc=arnd@arndb.de \
--cc=dvyukov@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox