From nobody Tue Sep 29 11:48:03 2026 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 DDA96243964 for ; Sat, 8 Aug 2026 10:57:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786186668; cv=none; b=RsTB+PWVFDgyICj2GM4uN557xlz/bbjSG/KJ1ho8BbaXA77w4YK+1F49h6yReXw2yS6LWI1xNmBqcWFSCfpbe5WB/IK8FgOCZZ4aRvVViZyEOiB8RFvJfFuyRFu/gPOzHqLCqq/6SqznH+ZWFeu0OfS+F9mWqioiS9wmlYfrOw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786186668; c=relaxed/simple; bh=J6KvawtO5UvDf4unv89oYzIRdqsfY2CABTLPZitSBew=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=ieHabT/b4ywu1FpDZfQxS+FmEfjE7l2wnE1PXra1fX1fIb+JK+rJN8LfK8vr9aNpMSkDgWbI5KeiSEctQ6btugYUNY/JKOFQ3CYNsl3/ZW4mjU/ecqYams+9CILawTStYiBzvg3WJpYERBzv73/+vrOqLWoWHytI84IShwfchlM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Xzu1bllK; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Xzu1bllK" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47fecbbafdaso60220f8f.0 for ; Sat, 08 Aug 2026 03:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786186665; x=1786791465; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=4uScLI4cpsUUGrfGmDNzyeUDMx7+1ql508c4euP1/Hk=; b=Xzu1bllKwEn2n1InJS8BM7Eyi0mpcdOrN94TSqQpI3//jxTy+ysmmP1g5OBLSEQgqc q8r9jXopo732pDMXqvUhUzb/rCDRhvcW7mNUHgOdh3Rwl6PPc4kBBc4b7sNUgnwPVf06 kKvbQsV2vqASCFHeTrhLJgaOe6SktYhitqZ6EiWJ9SJohfbAErdzrwVa8SNtI8Azx6jx 0p+CKWhWYtiKI7NNvXLe2R6jLDfrszB1CDleMuoKclFDyMpPp2EejnkrDUgQ2NNUIE2G /vKfg9NRQP20AK7vni0RSdHabLoG/wMZfV4tBVXDZ6vH/N3ljUr43GD2b3SxmwFMP9yw H3mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786186665; x=1786791465; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4uScLI4cpsUUGrfGmDNzyeUDMx7+1ql508c4euP1/Hk=; b=D60myZpc/IrJLDAHFc/D9Af8zYOboVcU3G+X4bjxtwvREabq+OHNrnExAK12Kvte7G +w5ahOCRsGt9v27IsWF6aZtrWZEzQqTj3Uc+QSWfQ1CLX51zD1YQp7gBZD2Kjzmu3xwX gVngtJYHr5nfvQeSnh6aK/gJmSdQheM+m292rQDDmuAeBl75nsuJZMqa8fqv5mjtjkVA QrRmDrW5slhoS8ENeZtl0C6fCStJ9s8fYb4Yrmx+Oes+qwk6C+Q+HZlctyYq4mAnZRL7 rcFtHk6tX0omcqv3TXuCMGtGZfl6Qg09kT5/V4a3ii6L24M151MaJjKHY5Rtma5E6FCl 54Dw== X-Forwarded-Encrypted: i=1; AHgh+RrPLAoWE2fCWm2xFT7Jyw0Bo6YDyL6Z3KPlVB17dP3CjPAlBaFo9aCScgnbdS8Vgo9rvj/RUbt/L2TIkWk=@vger.kernel.org X-Gm-Message-State: AOJu0Ywd98zdgBOhnDRlkyg21kYoIIKvHzzuH0hqtFYP+lCDkKv49UrF AKI77FYg3QqspskK/VqAQgXT8YwQCPYCXtWGJd8vfn6tXjLIEpx1tgCK X-Gm-Gg: AR+sD11hjSzaSQcdsuvRBtCf7+4IYC/mDVZSM/Za8IAaqlC4Ic1VDdtSiK4NFgWe9/7 yvoKng5wG/BwnpekKSt3PZH65386NJktasFMWqmpVdWqtLAWFvvjZy6pShUqAWAEXAwGn81oj7n CjUN5ac4Vtecrfe+Wn2jCiSolL+B8hiVt59K4NPiw0qJVk2bh7jyPVJ0dDzD02Be2e+4PYllcNP cnZ3QtMZkeWBaUBq/QP3fcxHCygHylMszpD75nGzbxIhurrue7W2nB09YDWGNRRSnIMyn/T82XZ 0wwG49d+Dq/m52pnvtiBp3FizigoWakLsMyHPCVExNb7lByDMV6mgJZx4QKK1cCenFCW9zsg4XN XtMuFwYbpkUcuYVvzH7U+6WHFri+FQ0dZYYjR7XeUCciKpwrPC/IGDcGB8OKxAmN3YCTR8bulBZ AnvI/qpDuO+4KfcFjfqSQyi4VcTtqANeDsIlOvj58rwpnjd1u6OBp6T9hh0XW0jlgIWYi5XGq4S uykrfJJF6FhpBU5T0oPf4rUHYs9SxPVuyPheU/eVHUo2cTz4OOT34KhSja1jFxLvaO10CjSDdDB LcDJ+zZqXyvuM+UhxS7aVikzcYBZDn4= X-Received: by 2002:a05:6000:2006:b0:480:c5:d635 with SMTP id ffacd0b85a97d-48000c5d6d9mr18245404f8f.0.1786186664921; Sat, 08 Aug 2026 03:57:44 -0700 (PDT) Received: from localhost.localdomain (dynamic-077-007-004-134.77.7.pool.telefonica.de. [77.7.4.134]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021506desm13940854f8f.10.2026.08.08.03.57.43 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 08 Aug 2026 03:57:44 -0700 (PDT) From: Karl Mehltretter To: Vlastimil Babka , Harry Yoo , Andrew Morton Cc: Karl Mehltretter , Rasmus Villemoes , Hao Li , Christoph Lameter , David Rientjes , Roman Gushchin , Catalin Marinas , linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: [PATCH] slab: align ZERO_SIZE_PTR to ARCH_KMALLOC_MINALIGN Date: Sat, 8 Aug 2026 12:56:22 +0200 Message-Id: <20260808105622.62026-1-kmehltretter@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The kmalloc entry points are annotated with __assume_kmalloc_alignment but return ZERO_SIZE_PTR, currently (void *)16, for zero-size requests. This violates the annotation when ARCH_KMALLOC_MINALIGN exceeds 16. This can mislead compiler optimizations. Current compilers retain the ZERO_OR_NULL_PTR() range check, but GCC and Clang eliminate an exact ZERO_SIZE_PTR comparison after an annotated allocation. Clang's UBSAN also reports the failed alignment assumption on armv5. Set ZERO_SIZE_PTR to ARCH_KMALLOC_MINALIGN when it exceeds 16 and keep the existing value otherwise. Assert that the alignment does not exceed 128, which keeps the sentinel below PAGE_SIZE and the low pointer poison values. Deriving the value from the architecture also avoids changing architectures such as s390, where low absolute addresses are valid. Fixes: 94a58c360a45 ("slab.h: sprinkle __assume_aligned attributes") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Reviewed-by: Catalin Marinas --- Notes: This version is based on the RFC discussion [1]. =20 [1] https://lore.kernel.org/r/20260712120728.96628-1-kmehltretter@gmail= .com =20 A tree-wide audit found no users depending on the numeric value of ZERO_SIZE_PTR. =20 The static assertion follows the ARCH_KMALLOC_MINALIGN fallback, the first point where the macro is guaranteed to be defined. =20 Tested on bcc44b6785f21: =20 - armv5, armv7, mips64, ppc44x and sh4 with minimum alignments from 32 to 128 - x86_64, arm64, riscv64, s390x and m68k as unchanged controls - Clang 21 with CONFIG_UBSAN_ALIGNMENT on armv5 no longer shows the alignment assumption report - no text, data or bss size change on armv5 or arm64 - the exact ZERO_SIZE_PTR comparison remains in armv5 code generation =20 The sh4 test needed two unrelated workarounds, both reproduced on the unpatched tree: compiling tcp_output.c at -O1 because of a GCC 15.2 hang, and disabling USB_OHCI_HCD because of an sm501-usb boot failure. include/linux/slab.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index 32c9f8ed7ae20..0798a714da87f 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -259,13 +259,16 @@ enum _slab_flag_bits { =20 /* * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests. + * It satisfies the alignment promised by __assume_kmalloc_alignment + * and keeps the historic value 16 where that is already aligned. * * Dereferencing ZERO_SIZE_PTR will lead to a distinct access fault. * * ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL c= an. * Both make kfree a no-op. */ -#define ZERO_SIZE_PTR ((void *)16) +#define ZERO_SIZE_PTR ((void *)(ARCH_KMALLOC_MINALIGN > 16 ? \ + ARCH_KMALLOC_MINALIGN : 16)) =20 #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <=3D \ (unsigned long)ZERO_SIZE_PTR) @@ -622,6 +625,12 @@ static inline bool kmem_dump_obj(void *object) { retur= n false; } #define KMALLOC_SHIFT_LOW ilog2(KMALLOC_MIN_SIZE) #endif =20 +/* + * Keep ZERO_SIZE_PTR below PAGE_SIZE and the low pointer poison values. + * 128 is the largest in-tree ARCH_KMALLOC_MINALIGN. + */ +static_assert(ARCH_KMALLOC_MINALIGN <=3D 128); + /* * Setting ARCH_SLAB_MINALIGN in arch headers allows a different alignment. * Intended for arches that get misalignment faults even for 64 bit integer --=20 2.53.0