public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com
Subject: Re: kcsan -Wmaybe-uninitialized warning in ntfs3
Date: Wed, 22 Apr 2026 13:51:20 +0200	[thread overview]
Message-ID: <aei2OEa1FGz36AOd@elver.google.com> (raw)
In-Reply-To: <CANpmjNNcGgqoA02QGCXcvDwkjcnk8BgCo6yTKu-B0VBVBJd4UA@mail.gmail.com>

On Wed, Apr 22, 2026 at 01:35PM +0200, Marco Elver wrote:
> On Wed, 22 Apr 2026 at 10:23, Marco Elver <elver@google.com> wrote:
> >
> > On Wed, 22 Apr 2026 at 10:00, Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Apr 21, 2026, at 21:12, Arnd Bergmann wrote:
> > > > On Tue, Apr 21, 2026, at 21:06, Marco Elver wrote:
> > > >> On Tue, 21 Apr 2026 at 17:26, Marco Elver <elver@google.com> wrote:
> > > >> [...]
> > > >>> > To me, 2 makes more sense. The attribute requires gcc-11 or higher,
> > > >>> > so you need to wrap that in a compiler version specific macro,
> > > >>> > but since I only saw the warning with gcc-12 and higher, that
> > > >>> > should be fine.
> > > >>
> > > >> Kindly test if you can:
> > > >> https://lore.kernel.org/all/20260421190351.1976329-1-elver@google.com/
> > > >
> > > > Applied to my randconfig tree and verified that this fixes the
> > > > known warning (only one out of about 200 random configs). I'll
> > > > let you know if something comes up by tomorrow.
> > >
> > > Unfortunately, there are new warnings after your patches using
> > > gcc-11. In 500 randconfig builds with that compiler, I saw 7
> > > configurations failing with one of these four messages:
> >
> > Looks like a compiler bug to me; can you check gcc-12+ ? Maybe we need
> > to allow the __access attribute only for later GCC versions.
> 
> I can also see this warning with later GCC - so I'll give up on the
> __attribute__((access)) version and instead suppress warnings.

The simplest solution I found so far:

diff --git a/include/linux/kcsan-checks.h b/include/linux/kcsan-checks.h
index 92f3843d9ebb..989fd21841ba 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
@@ -291,7 +291,7 @@ static inline void __kcsan_disable_current(void) { }
  * @size: size of access
  */
 #define __kcsan_check_read_write(ptr, size)                                    \
-	__kcsan_check_access(ptr, size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
+	__kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
 
 /**
  * kcsan_check_read - check regular read 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
@@ -317,7 +317,7 @@ static inline void __kcsan_disable_current(void) { }
  * @size: size of access
  */
 #define kcsan_check_read_write(ptr, size)                                      \
-	kcsan_check_access(ptr, size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
+	kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_COMPOUND | KCSAN_ACCESS_WRITE)
 
 /*
  * Check for atomic accesses: if atomic accesses are not ignored, this simply
@@ -331,9 +331,9 @@ 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)
+	kcsan_check_access(absolute_pointer(ptr), size, KCSAN_ACCESS_ATOMIC | KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND)
 #endif
 
 /**

  reply	other threads:[~2026-04-22 11:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21  7:53 kcsan -Wmaybe-uninitialized warning in ntfs3 Arnd Bergmann
2026-04-21  9:33 ` Marco Elver
2026-04-21 10:21   ` Arnd Bergmann
2026-04-21 11:35     ` Marco Elver
2026-04-21 12:28       ` Arnd Bergmann
2026-04-21 13:18         ` Marco Elver
2026-04-21 14:11           ` Arnd Bergmann
2026-04-21 15:26             ` Marco Elver
2026-04-21 19:06               ` Marco Elver
2026-04-21 19:12                 ` Arnd Bergmann
2026-04-22  8:00                   ` Arnd Bergmann
2026-04-22  8:23                     ` Marco Elver
2026-04-22 11:35                       ` Marco Elver
2026-04-22 11:51                         ` Marco Elver [this message]
2026-04-22 20:57                       ` Arnd Bergmann
2026-04-22 21:50                         ` Marco Elver
2026-04-23  8:12                           ` David Laight
2026-04-23 11:35                             ` Marco Elver
2026-04-23 13:06                               ` David Laight
2026-04-24 10:03                                 ` Marco Elver
2026-04-21 12:26     ` 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=aei2OEa1FGz36AOd@elver.google.com \
    --to=elver@google.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=arnd@arndb.de \
    --cc=dvyukov@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    /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