All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.