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 A4D0A3C5DCD; Thu, 19 Mar 2026 11:00:17 +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=1773918017; cv=none; b=H5grbvv24zBE27+VRJO/anEvDIcmvMDa7xyzocrZUM/Uwlr4j7+60nFE7PH5+T6bTa71aaWn4mceVL6eeX6mm3w286NzXkU3PkTavxCjuyPRfBa9X1bmQyVUYw/dsjix2O5W0/5sb8HJgg6brpAD/c1oVFot7Xqw+8dX6s+FgmM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773918017; c=relaxed/simple; bh=MBof8FJxF37YeVM6q8qyel1Ver5Rcon2mZ9n85w9do8=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=RoRGoNR59UjKPfRdfi/Nso+ExQs0YN4za6+be+XyzYZs8aYI/qL3nvsI6DPderf+xvfOrKj/nDTUTvLEdlSNR5KNxYcjb5YYdfVruCZuknlK3hjbe+ADCxnYN/PkbzZNoNxW3ei1iQpBjab0U9Vw4ypM5r2pdNRf+z/PBZWDINE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l7wF+H5B; 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="l7wF+H5B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35122C2BCAF; Thu, 19 Mar 2026 11:00:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773918017; bh=MBof8FJxF37YeVM6q8qyel1Ver5Rcon2mZ9n85w9do8=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=l7wF+H5Bo3Vh+VwVYT5cpUORpkk7ozwmt5FWizkVmeGsZnPh+gsB9UVJLKeBm0d76 mhM16zE7UKqSbJbVq070t6PcHbDQh40Z0gwRl+QOcCyrJq9mkxgajSLFim6PtpdJX1 c8RwjIRT/VNIq/MAt7k4VQFI4FggsnxWUNnxwz9jb6HSr0hengKbUIIKei41KhJHqZ ZQFFgO5xXvMJ1GH6b9WeUgqnQJhPhCQ0ju1SYeh+wx/ukbwRokArXDFogd+0SX501s COWFFeizdmlJ0J4o82xwEfOg4mx5WtHaXxSmdzQbfe9etUJV6xMrpG50e/3ECf7z6a wfu3tPLHPeUgg== Message-ID: <48f29e10-e9e9-4d07-8491-a4403ace5859@kernel.org> Date: Thu, 19 Mar 2026 19:00:09 +0800 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, stable@vger.kernel.org Subject: Re: [PATCH v2] f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode() To: Cen Zhang , jaegeuk@kernel.org References: <20260318073253.3108313-1-zzzccc427@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260318073253.3108313-1-zzzccc427@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/3/18 15:32, Cen Zhang wrote: > f2fs_update_inode() reads inode->i_blocks without holding i_lock to > serialize it to the on-disk inode, while concurrent truncate or > allocation paths may modify i_blocks under i_lock. Since blkcnt_t is > u64, this risks torn reads on 32-bit architectures. > > Following the approach in ext4_inode_blocks_set(), add READ_ONCE() to prevent > potential compiler-induced tearing. > > Fixes: 19f99cee206c ("f2fs: add core inode operations") > Cc: stable@vger.kernel.org > Signed-off-by: Cen Zhang Reviewed-by: Chao Yu Thanks,