From nobody Sun Feb 8 17:36:55 2026 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (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 D2E322DB797 for ; Mon, 2 Feb 2026 09:41:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770025281; cv=none; b=bj6OoRYDofPUPfHFyWxEQteC1ZpntS6z1U5oimam0v+wSegr42DrGRbqcJUFYIBTMkOyyvdWtQYAxVhil+9p8+c8mMyb57dKXW9tqCvQWlaFxdodghwYvb1IPLhNKmWFZ3WPuMlBMWlAJ03kYMJYeMr7L+cTFRf60aSVMvqRAzQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770025281; c=relaxed/simple; bh=eUfPgtPNfSD6KYh4cmkw4wZBG3zn+FqSuYw5On2O4ps=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JolIpYib5uDW3BfUrHxwZOMh85vEPTwGjSS9Wl3SgL2dCg49jGT/jqGspGH77fRotvHNkFqzeADzbia2lW0sPqo0G1No0r4/eL1jQzc49BzD3fKZHIZA1v0u6p+3aorDJVVJN5hjJlv+/49V3hqLwVjjkAKceC8vSCFnTmXgjy8= 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=TvWgwrUd; arc=none smtp.client-ip=209.85.210.170 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="TvWgwrUd" Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-81e8a9d521dso2390498b3a.2 for ; Mon, 02 Feb 2026 01:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770025279; x=1770630079; 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; bh=H88SZSbXV2e3lJ3GkI7Q4VnrUVrg0jvpUWITWiHU6MY=; b=TvWgwrUdNz5BYpFsD6j/PhBHxjOfQZ/b1KCnRgaR77Zd0D4JF+T03V1w/CSGXXhV9f 7TKtj7ErQzBqYTUlk8C5rVFCyScg4pcy9vh5zaxQtO2hWWy9aMD05OeoLTf1kHfTdSTQ A5WOqtZiV3MXyiuMgb0FUHtX7g8UD5anCpZezc25JtQx7O2jSCaEvc6yDsykcwvXYvMI 4xTqZICP2k+n37JRSQDJqoJzJ7L6gefYH0SmIAOxmj/DfpJfjqr8SAIgA6yd7X10AmIY 4ORgiV9VqV+/uqyFc3NdkxABP9/+Mo6kob7ZlB215ONlwdUbauz4pWm7ETeFk8cKN/KE xu2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770025279; x=1770630079; 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; bh=H88SZSbXV2e3lJ3GkI7Q4VnrUVrg0jvpUWITWiHU6MY=; b=ovJJjA8UisSlCROzieDmTcYKTOZBhnvQ0wSokUnpL9O2GWY1WdONAlbAV1A6pTeRdZ 4yXe2E0v7Q4kGyi9t+b1BbpuC/oSCyDOcN0xYKhqmCTlawsJ6bgZqXQZ5D7Sq0GXMvKu /Rku7cDHB7bru3lkT1wUePykgmuddgUX4au6W+NEXEdpHv52X+1RPbTxoqQ8lu2dYTPC un/29c125FjZzyLAhjjtVAMlYmex8xFVMNS9pgf+PdK25yMn6hId2trMYaZNTToto2US Dl6djT/Y6n7dNCE0JWOpDVkA/3kiIewfiXEHWSPhOlYz/w/rNdDhiTEavllKMx8WCEtR yA5Q== X-Gm-Message-State: AOJu0Yy8GvV4qX6EiX5M7LFLkC7VFUijEKtAJfLifpwGCTD1+g3GPtLS CMyTNs4ZGEODcfCGbyXvuXBfZSBo3GF5gaLnPLO/wtaG9aq12G61cQF8jyUTZQ== X-Gm-Gg: AZuq6aKUbugaOuLGKXuc6u1iF71JYEC4qoswd2rSSGe6BbItolS2zVcTCW9TLvEAPxr jwue3Ufq+XxOvAUNfV9mKCqKIB4LD0c8BbCNr84gO/hjOnOWCRXAFE152xhVFQOMWvbK76gPHRt ORPQEp/zZv41BNE8Ri3KoMPig+uTVRQluumt6qlfWZ6qWQVCUGKw5AEccQsSI5n9z0QhHe0JNHv PRP+rMEHV7vn2N+LkhgPymLNK8jpIFe5GtRfXB69o+FZQuiSapEk//dW/hSW/r19OhABe/vtGx2 foMbiAXWdWVKLgphHRyVFEgvHODXJTxfNzyUR/5D0ZI1Z2oNu6Ney57Yay4T8DSscoLmFx4+7GI AgVvXJOiK+yhW4BVCp7Y40dw7g56HsUH2O+1s1oEVFowmn3Gy6mjsNc/oTL6L846lxmmdOgsWoS xDWEr3zH1YJ7WWy11PuZe7DC4dXc8A6zZRvy9H6Iw= X-Received: by 2002:a05:6a00:21d4:b0:81f:45a9:1a58 with SMTP id d2e1a72fcca58-823aa53649dmr9714812b3a.23.1770025278589; Mon, 02 Feb 2026 01:41:18 -0800 (PST) Received: from PC-PF4KNQBS.Xheart.com ([202.46.41.90]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82379c22419sm15598697b3a.46.2026.02.02.01.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 01:41:17 -0800 (PST) From: "feng.zhou" To: linux-kernel@vger.kernel.org Cc: pmladek@suse.com, senozhatsky@chromium.org, rostedt@goodmis.org, john.ogness@linutronix.de, "feng.zhou" Subject: [PATCH] printk: Fix _DESCS_COUNT type for 64-bit systems Date: Mon, 2 Feb 2026 17:41:40 +0800 Message-ID: <20260202094140.9518-1-realsummitzhou@gmail.com> X-Mailer: git-send-email 2.43.0 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 _DESCS_COUNT macro currently uses 1U (32-bit unsigned) instead of 1UL (unsigned long), which breaks the intended overflow testing design on 64-bit systems. Problem Analysis: ---------------- The printk_ringbuffer uses a deliberate design choice to initialize descriptor IDs near the maximum 62-bit value to trigger overflow early in the system's lifetime. This is documented in printk_ringbuffer.h: "initial values are chosen that map to the correct initial array indexes, but will result in overflows soon." The DESC0_ID macro calculates: DESC0_ID(ct_bits) =3D DESC_ID(-(_DESCS_COUNT(ct_bits) + 1)) On 64-bit systems with typical configuration (descbits=3D16): - Current buggy behavior: DESC0_ID =3D 0xfffeffff - Expected behavior: DESC0_ID =3D 0x3ffffffffffeffff The buggy version only uses 32 bits, which means: 1. The initial ID is nowhere near 2^62 2. It would take ~140 trillion wraps to trigger 62-bit overflow 3. The overflow handling code is never tested in practice Root Cause: ---------- The issue is in this line: #define _DESCS_COUNT(ct_bits) (1U << (ct_bits)) When _DESCS_COUNT(16) is calculated: 1U << 16 =3D 0x10000 (32-bit value) -(0x10000 + 1) =3D -0x10001 =3D 0xFFFEFFFF (32-bit two's complement) On 64-bit systems, this 32-bit value doesn't get extended to create the intended 62-bit ID near the maximum value. Impact: ------ While index calculations still work correctly in the short term, this bug has several implications: 1. Violates the design intention documented in the code 2. Overflow handling code paths remain untested 3. ABA detection code doesn't get exercised under overflow conditions 4. In extreme long-term running scenarios (though unlikely), could potentially cause issues when ID actually reaches 2^62 Verification: ------------ Tested on ARM64 system with CONFIG_LOG_BUF_SHIFT=3D20 (descbits=3D15): - Before fix: DESC0_ID(16) =3D 0xfffeffff - After fix: DESC0_ID(16) =3D 0x3fffffffffff7fff The fix aligns _DESCS_COUNT with _DATA_SIZE, which already correctly uses 1UL: #define _DATA_SIZE(sz_bits) (1UL << (sz_bits)) Signed-off-by: feng.zhou --- kernel/printk/printk_ringbuffer.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringb= uffer.h index 4ef81349d9fb..4f4949700676 100644 --- a/kernel/printk/printk_ringbuffer.h +++ b/kernel/printk/printk_ringbuffer.h @@ -122,7 +122,7 @@ enum desc_state { }; =20 #define _DATA_SIZE(sz_bits) (1UL << (sz_bits)) -#define _DESCS_COUNT(ct_bits) (1U << (ct_bits)) +#define _DESCS_COUNT(ct_bits) (1UL << (ct_bits)) #define DESC_SV_BITS BITS_PER_LONG #define DESC_FLAGS_SHIFT (DESC_SV_BITS - 2) #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT) --=20 2.43.0