From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFA37C6FD1C for ; Thu, 23 Mar 2023 14:19:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231304AbjCWOTs (ORCPT ); Thu, 23 Mar 2023 10:19:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230231AbjCWOTQ (ORCPT ); Thu, 23 Mar 2023 10:19:16 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D814D7681 for ; Thu, 23 Mar 2023 07:19:14 -0700 (PDT) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 32NEInaa001556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Mar 2023 10:18:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1679581131; bh=cGD8jvsfa9IIYRW5RRrX3cUET8CNS99iIvfOWiCAkM8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=a8gn2XBSn61rTvA9THZMLq1sHhazldZ6opzjvVDg7Pr1ea4gSPtgwMQxuAplyBxJ/ SH8HJFsUOGpi/y/JZcBUKZj6WOpOvHagaQQyMgzy7cuDCuEfXKSVAWhKIfFhji6Uvg h1YnLBt5rqGsYdSVM3uxzZ+b/cvgVNSFB0P7m/epKz1tK/edoAZQey7wZcl/1FzdiD v9JvxxmxULL2NIthhGI9ZVACQLVtz2N7/Co9GgWLt0105/CJz7K7UBScaT+E3gE43N 1lONi5UFR9RdwM2+zkGm06kA+P9iVJ5rW392yI877lUhWrY/zHdiKZv43CDVqHlcto ijOvmkONLn+1w== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 424E815C4279; Thu, 23 Mar 2023 10:18:49 -0400 (EDT) Date: Thu, 23 Mar 2023 10:18:49 -0400 From: "Theodore Ts'o" To: Kemeng Shi Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, error27@gmail.com, jack@suse.cz Subject: Re: [PATCH] ext4: avoid to access uninitialized block_cluster Message-ID: <20230323141849.GA136146@mit.edu> References: <20230320212106.4164212-1-shikemeng@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230320212106.4164212-1-shikemeng@huaweicloud.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 21, 2023 at 05:21:06AM +0800, Kemeng Shi wrote: > If inode bitmap block and block bitmap block are in different group, > there is a risk to access uninitialized block_cluster in > ext4_num_overhead_clusters. Initialize block_cluster to -1 to fix this. > > Signed-off-by: Kemeng Shi > Reported-by: kernel test robot > Reported-by: Dan Carpenter > Link: https://lore.kernel.org/r/202303171446.eLEhZzAu-lkp@intel.com/ > Fixes: e3c70113e2cb ("ext4: improve inode table blocks counting in ext4_num_overhead_clusters") Thanks for the fix-up and to Dan and the zero-day test bot for noting the problem. Since I've needed to rebase the ext4 dev tree to pick up an urgent fixup as well as deal with some other problematic commits, I've merged this fix into the base commit "ext4: improve inode table blocks counting in ext4_num_overhead_clusters". Cheers, - Ted