public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
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>, Miguel Ojeda <ojeda@kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	 Nathan Chancellor <nathan@kernel.org>,
	llvm@lists.linux.dev
Subject: [PATCH 2/2] kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()
Date: Tue, 21 Apr 2026 21:03:48 +0200	[thread overview]
Message-ID: <20260421190351.1976329-2-elver@google.com> (raw)
In-Reply-To: <20260421190351.1976329-1-elver@google.com>

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 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.

Silence the warning by annotating `__kcsan_check_access()` with
`__access(none, 1)`. This tells the compiler that the pointer is not
used to access the referenced object, avoiding the false positive.

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>
---
 include/linux/kcsan-checks.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h
index 92f3843d9ebb..3a44f90ebd2b 100644
--- a/include/linux/kcsan-checks.h
+++ b/include/linux/kcsan-checks.h
@@ -34,7 +34,7 @@
  * @size: size of access
  * @type: access type modifier
  */
-void __kcsan_check_access(const volatile void *ptr, size_t size, int type);
+void __kcsan_check_access(const volatile void *ptr, size_t size, int type) __access(none, 1);
 
 /*
  * See definition of __tsan_atomic_signal_fence() in kernel/kcsan/core.c.
-- 
2.54.0.rc2.533.g4f5dca5207-goog


  reply	other threads:[~2026-04-21 19:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 19:03 [PATCH 1/2] Compiler Attributes: Add __access macro Marco Elver
2026-04-21 19:03 ` Marco Elver [this message]
2026-04-21 19:15 ` Miguel Ojeda
2026-04-21 19:20   ` Marco Elver
2026-04-21 19:30     ` Arnd Bergmann
2026-04-21 19:35       ` Marco Elver
2026-04-22 10:25       ` Miguel Ojeda
2026-04-22 10:30         ` Miguel Ojeda
2026-04-22 13:22         ` David Laight
2026-04-22  5:50 ` Nathan Chancellor
2026-04-22 10:01 ` David Laight
2026-04-22 10:20   ` Marco Elver
2026-04-22 13:06     ` Marco Elver
2026-04-22 10:25   ` Miguel Ojeda
2026-04-22 13:02     ` David Laight

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=20260421190351.1976329-2-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 \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ojeda@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