From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9461C2E8B94 for ; Tue, 10 Feb 2026 13:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770730868; cv=none; b=Fuvbthv6QCeJkd8s48vEqsHYocmkj9vNPzvA3yuWOGhFm4xSJEXD2sNw/EHJzHxtsLZ3aJv0VMBQEq6lqMR/uOLj1zkx6xzj3gp79WUiHbafnHugbyNjj8O07yWQgFNnfO89v4nBV16hCrgnYBDfKZ5j7EirmwmCf7QMCDEUoHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770730868; c=relaxed/simple; bh=MT+rctIKmuvnA5eIBAxzoWBQTwTyMz/PD/htQtTMRHA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=rn3SPmHTi3mZe2QKqCr0rMv7X4r0E347foKaqs9xVoUXX5i0/Bg0mZd7cKqExiAtZ1abKlUjqrTtr12A6ETvCupeRCJnyaeoTAxpNj2L/CQCl+5zYFKBnpPdE9fZ+natPXzoD3y96NrLcXuyxvxqPIlQow+XgwrTAp6W+75Aqww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nIllKt5t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nIllKt5t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9288C116C6; Tue, 10 Feb 2026 13:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770730868; bh=MT+rctIKmuvnA5eIBAxzoWBQTwTyMz/PD/htQtTMRHA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nIllKt5tMFMZhddu4EvDabsmw0eHTKy8WZOr+dKIUK3L85tK4gxTBXSx759Vo8FSP UEUEtJQRapO+RGb5Lej1n6r3xYUdyvdxWW6Xey2r3uABmMd57mYgPNF/1Vlizl4A/y 2Lan/KlFtdWKApPbiTGiOpjdxcEhW5ODyj7+1LjCroZc7eJcd4z7PKmoVr9lV2hUUR hLDipo1c38yuDNcZaraPl5Four8CUKGTqKpey2Dkjbh8XtIagfqAnKbKvqvYZnrhIb XX/7t3NPvotDvDyaeHdjj7EwR++IqchPlbh/kdhhIuc3QtygKOiXDz2mIWRIrKu/SA o00paYupoA1MA== From: Pratyush Yadav To: David Binderman Cc: "graf@amazon.com" , "rppt@kernel.org" , "pasha.tatashin@soleen.com" , "pratyush@kernel.org" , "kexec@lists.infradead.org" , "linux-mm@kvack.org" , LKML Subject: Re: linux-6.19-rc8/kernel/liveupdate/kexec_handover.c:1089: Possible 32/64 bit mixup ? In-Reply-To: (David Binderman's message of "Thu, 5 Feb 2026 09:21:17 +0000") References: Date: Tue, 10 Feb 2026 14:41:05 +0100 Message-ID: <2vxzzf5gsolq.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Hi David, On Thu, Feb 05 2026, David Binderman wrote: > Hello there, > > Source code analyser cppcheck says: > > linux-6.19-rc8/kernel/liveupdate/kexec_handover.c:1089:15: style: int result is > assigned to long variable. If the variable is long to avoid loss of information, > then you have loss of information. [truncLongCastAssignment] > > Source code is > > contig_pages = (1 << order); > > I admit the error message is hard to understand, but AFAIK > if local variable order remains under 30 or so, then there is no problem. > > However, if it goes above 32, then there will be loss of data. > Expression 1 << order is type int. > > Suggest add some code or comment to document the expected range > of local variable order. If it ever goes above 32, suggest new code > > contig_pages = 1UL << order; If order is 32, with 4k pages, that means 16 TiB. It is unlikely that we will see vmalloc area backed by pages this large any time soon. So I am not worried about any practical problems. But I think this is still a good idea to do for code hygiene. So a patch would be much appreciated. -- Regards, Pratyush Yadav