From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB7413DB63C for ; Tue, 21 Apr 2026 19:04:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776798250; cv=none; b=lcTgjanyGbkyw0ORPVJy7sY9A8eMqYqQ236xWljgq40uOak1f/jMNJsbHVXwuHEiZW34vVPlOnSQc0A8gjXWMEB3LsWj+oR+BttbKNOJDblsS9XaxVR/EKpeyqWCK84Ab7gqUexZ2pJU/RLZlQkiJnhSnA8zZXhUnjlSJTbe928= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776798250; c=relaxed/simple; bh=+TIjHenySK7KBMmnDPQWgEZ4N7BSlTONF2U6rWErhRs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=n5WZUIb2RQ919baNEHJgBjGYhCTdd8aPIlrCF4XDl16EYhv6znOZL6F6c9Nnko6ezFsn4EkgRRXq/VJjg1bpRKsqAbxbnNAOyRgUeF/cBd8lbxPBSmwzwS0znjNrIY+3w+QhqjL6awfrHBbE1G1iEolYstNp/S427T5L6RhrZ2I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--elver.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=TVjJ6M7l; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--elver.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="TVjJ6M7l" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-48a55d82e0eso7072015e9.1 for ; Tue, 21 Apr 2026 12:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776798247; x=1777403047; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=/bsDKIazjoUvS+1au3+tBOKUvZ6ecoU1stpalOdMHw4=; b=TVjJ6M7lUTgXn2bzzrbuPkYbDZuWNA90YeBctAlNF24wNMd/ihkmNsL5q5USgqWkCA T81zK1EF2coG5sn/gstcXnEo7nWwXF4T3JqDgD9je148+RRDfmH8RA3mJYXVRr9UV/Ei VdUqQhFEkSTt8x6BIp/lteOI/9189zb+jJAQ1Xp64TNIl9I+wz5gEY5sq7gQYzIaVde8 fT0Pf077TeyKfYwmEBmW3SJ6ZAbnPtjpPB3G7u8RIXyiJkgCECEj/YF5mKOjGYvLD+nC 94iofDMh3B9+SksOWqyWrAcglSQzN7/r1kR4k+BMV5KewyoApDozhQ4j3j4BrcbFXYoC TFFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776798247; x=1777403047; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/bsDKIazjoUvS+1au3+tBOKUvZ6ecoU1stpalOdMHw4=; b=FpQshciP7NhBUHPXs0kGs3bP6nPvJSYUvd/Z8BovjuXV6ZWBRsCD0zIm8EK8P1I6en PXl78XuSb6eICBn0P1EzyDVbv8FiSdVSwfwTfaw0W7/Q7tAnIGsFlegguaj53m4pfEQi 4E8l+87qsaSevtNU+WoKsedm6pHAVePm1NhSeDZPAjqvY3ZpaWyd7R1LF4A5MEhzr0Gu ISZWeMXsKA8Fu9wEA0v1VhndMNLEYxii6rPqfD9RXoImp9Jvd0eT6HX9dxaZyxNtFbVP 5M0jHmYbclOPUEmz6DAPchl4TXd3UOQYFRxfgLNFZYMY+oK1XBA2AZOvjBbr3dA2PW/s dNfA== X-Forwarded-Encrypted: i=1; AFNElJ+Jw+F32RJxJwU3hdKAHSXNKodRni4r+oToyCkg951QCoCU3BiMtXX6M2owJvOofp+tsW70RCalElO9h1E=@vger.kernel.org X-Gm-Message-State: AOJu0YyngfFk15SmxdxUvlQxaWWUdvs8q/4TOPImcJHmIA+ZKHG1Qj/2 JVDmVmz0X//uuchStQ6PhsKA2QQlSKvyiTwLlDJMIIL5V2QSlC3OsV2+iN/JDN50O7YwMq7R/mm f3Q== X-Received: from wmbd5.prod.google.com ([2002:a05:600c:58c5:b0:487:38f4:9550]) (user=elver job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:19c8:b0:48a:554d:b9a2 with SMTP id 5b1f17b1804b1-48a554dba51mr69868525e9.6.1776798247249; Tue, 21 Apr 2026 12:04:07 -0700 (PDT) Date: Tue, 21 Apr 2026 21:03:48 +0200 In-Reply-To: <20260421190351.1976329-1-elver@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260421190351.1976329-1-elver@google.com> X-Mailer: git-send-email 2.54.0.rc2.533.g4f5dca5207-goog Message-ID: <20260421190351.1976329-2-elver@google.com> Subject: [PATCH 2/2] kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access() From: Marco Elver To: elver@google.com Cc: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Arnd Bergmann , Miguel Ojeda , Dmitry Vyukov , Nathan Chancellor , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" 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 Signed-off-by: Marco Elver --- 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