linux-kernel - [RFC PATCH 0/1] compiler_types.h: introduce ASSUME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250723140129.276874-1-rakagunarto@gmail.com>
Date: Wed, 23 Jul 2025 15:01:29 +0100
From: Raka Gunarto <rakagunarto@...il.com>
To: linux-kernel@...r.kernel.org
Cc: Raka Gunarto <rakagunarto@...il.com>
Subject: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis

This proposed patch introduces a new macro ASSUME_NONNULL to suppress false
positives of null pointer dereference warnings during static analysis.

The patch only includes the macro definition for Clang so far, as I could
not silence GCC's static analyzer false positives without ensuring that
it wouldn't affect the emitted code.

I tested this patch and use of the macro successfully eliminates false
positives when used properly and does not affect final code generation.

I am new to contributing to the kernel, so I apologise in advance for
any mistakes. I welcome all feedback or suggestions for improvement.

Rationale:
- Use of this optional macro can silence false positives which may reduce
  patches that fix false positives (such as AI generated patches).
- Clear documentation of a non null assumption for other developers
- Signal to reviewers to subject patches that use this macro to
  additional scrutiny, and require justification on why
  there isn't a null check in the code instead.

Motivation:
While running Clang's static analyzer on the Linux kernel, I encountered
hundreds of false positives related to null pointer dereferences.
One such example is in mm/slub.c, where the static analyzer
incorrectly reports a potential null pointer dereference on line 3169.

n is non-null at that point, but it is non obvious to the static analyzer
(and to humans) that get_node() will always return a non-null pointer.
Since it is in a performance crtical context, adding a null check
would be undesirable (I think). A macro like this can be used to
signal the pointer is invariably non-null, without adding a runtime
check.

Raka Gunarto (1):
  compiler_types.h: introduce ASSUME_NONNULL macro for static analysis

 include/linux/compiler-clang.h | 10 ++++++++++
 include/linux/compiler_types.h |  5 +++++
 2 files changed, 15 insertions(+)

--
2.43.0