From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 51B573BBA1A for ; Tue, 10 Mar 2026 16:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773160657; cv=none; b=dX8xKVQEe1YQn1sh8U+yUYFcFVqIJIXS4/mDDjDRFsuAbvq3fs/alaBJlqQ1neNQ/XcZj+RABKTAZBjXHZlMnbCgTvVjOz0+kJT4bHDb3lQXBEiignvKF08H18S0/by+pcStW7kwRAxVzALWN8otHm8Nq4R1U/ETITKk8JJZ0Vo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773160657; c=relaxed/simple; bh=FMA42g4vcskawGE4ySBzJW0SsJ3dNbFOAKdK9XLYurk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qwy+u0/am3saWwh+qD6t+dTa1ITWslJVzVcLvhS19xG9GGANWT66mskitThfEOUVPyl9nk/pUnI+vHTUQIbaopxYUs7UOa+jVV05sM4hDWAuvI/IiGp7XaKwoUCqRkh/yxMq4ycEYV5G9f4Utl3DMFRqxen2LPW4viM5metT7u8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=QSycu5Ob; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="QSycu5Ob" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-439b94a19fdso8639195f8f.0 for ; Tue, 10 Mar 2026 09:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773160655; x=1773765455; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IVWzfZkciSjHpAV/mKrI/+lqVy9AnSpUAmHN53VHN5U=; b=QSycu5ObSezbnvHW3jy8Hdmj9LI5ebfIVLNuHmOKWUgVjjOcKRTYHhzbfn9uTmoT6w VjVFDar9GL8rNwsSkw8b0gMKfRQek9XhvtLpxA7hbTcfcrUq3Ge37wm2qUlAlCKiA7Je UVJAyX90MBWHjyWK7/IwnHzyyUJIU+u/rpaq+XhxWPJDviMr8HG8Sa/L/v0y7OVUlwpA f2xxSPq7QAmf2hnghKlLzd1Xly3SZTGtBMs1/vF4pNLZ/qwiwDvrku5g/qyj6En3i6N1 YULDIfn3J1eOW5OX4cLpERMCAJ5ClMDzLJgBQbmWAuug5PfY1Uu76x56s1Uu6JWhgVrv iFCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773160655; x=1773765455; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IVWzfZkciSjHpAV/mKrI/+lqVy9AnSpUAmHN53VHN5U=; b=nHQ6waDFnzSW/SjLXNqFwzqssA5LDqP9b78b7XFyobV8GIVz0iUZxIKfeuhMDgLhk5 sHJbmzLsYW4Z9icUNS1LrO66nxJPDEHpFONKi9x3G9sBhK2k0mALKXBBNffPPUsZzWnl sl2cxBlYdcNFjrZPMxCiPOOtYdSptOmqRnv+sAp2ZySq++rwQwtyECjT8I2ZYMA2ZFCh pQfqnBsOEfT7gGGQ4yXUi4BZ8qOZ6t9McuUvAuypVvtyhQ0G+jbEYfQPtaBHFwO8pJao +VizDXuplDppyv5KplX2krIBHKda4p0n3axPjfuF7VQescx4FLBs9IKU+22mAot9tR2o oDpg== X-Gm-Message-State: AOJu0YzifoAIAASCZCQZsJPcr9aJ69WlWw3SjnMyfqVedjENGWCjmig4 EP5XA/OXiQgEr0mN4dbUXyhqwLv9WOU6x9quOoLshYH/oLvAIXEU2wDNEA9HLzfSLC0Kr5C5vat F5mbl X-Gm-Gg: ATEYQzwx3374Wy+0GNjVZXmIAn1k3S+NgntCKitgPGlPHSh/i8xe+R7rdKPWfFjS8/8 7DW0PME/jcvNq0+uSogKHxQgTsCIpYuUYBATselc4CqmIPFv9kADINccssYDPayltJyzmqWMoRI ODBg7dxhVeWzAZOSxeXEWk1E/RlNSFwjYBFVbeWedWBYP30M/C0X2Hq0inYBY/KOMRwunBAuP4x a9oq+Mz0Ue3bY7yKz/DTOXE+TSareFUcNIA1iYOhjOTqjs50MADMJBpUtXSFs1sldg1/bd20oYy hNXVxeVpn6wtjI3UfRHYvn2NzRzTKTDHkQGZhlunGUvyMSuEvMmMMxSsKfAEgCV8Lmt0gBK1lSk wVKnBm1r1XE7vvLh0aNZru5Nw65qpyhLMYdvyXvVp2s0XBFF94wgpSnAPSO92xPEjK2raEvR9V6 2IEj2NXeF8lst0IUg/HMgSzss7Tg== X-Received: by 2002:a05:6000:2c03:b0:439:cb79:ab05 with SMTP id ffacd0b85a97d-439da88bb1emr26785902f8f.36.1773160654617; Tue, 10 Mar 2026 09:37:34 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae3f267sm35628312f8f.31.2026.03.10.09.37.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 09:37:34 -0700 (PDT) Date: Tue, 10 Mar 2026 17:37:32 +0100 From: Petr Mladek To: "feng.zhou" Cc: linux-kernel@vger.kernel.org, senozhatsky@chromium.org, rostedt@goodmis.org, john.ogness@linutronix.de Subject: Re: [PATCH] printk: Fix _DESCS_COUNT type for 64-bit systems Message-ID: References: <20260202094140.9518-1-realsummitzhou@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260202094140.9518-1-realsummitzhou@gmail.com> On Mon 2026-02-02 17:41:40, feng.zhou wrote: > 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) = DESC_ID(-(_DESCS_COUNT(ct_bits) + 1)) > > On 64-bit systems with typical configuration (descbits=16): > - Current buggy behavior: DESC0_ID = 0xfffeffff > - Expected behavior: DESC0_ID = 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 = 0x10000 (32-bit value) > -(0x10000 + 1) = -0x10001 = 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=20 (descbits=15): > - Before fix: DESC0_ID(16) = 0xfffeffff > - After fix: DESC0_ID(16) = 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 JFYI, the patch has been committed into printk/linux.git, branch rework/prb-fixes. Best Regards, Petr