Received-SPF: pass (google.com: domain of linux-ext4+bounces-1269-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Srivathsa Dara <srivathsa.d.dara@oracle.com>
To: Maximilian Heyne <mheyne@amazon.de>
CC: "ravib@amazon.com" <ravib@amazon.com>,
        "stable@vger.kernel.org"
	<stable@vger.kernel.org>,
        Theodore Ts'o <tytso@mit.edu>,
        Andreas Dilger
	<adilger.kernel@dilger.ca>,
        Yongqiang Yang <xiaoqiangnk@gmail.com>,
        "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Rajesh
 Sivaramasubramaniom <rajesh.sivaramasubramaniom@oracle.com>,
        Junxiao Bi
	<junxiao.bi@oracle.com>
Subject: RE: [External] : [PATCH v2] ext4: fix corruption during on-line
 resize
Thread-Topic: [External] : [PATCH v2] ext4: fix corruption during on-line
 resize
Thread-Index: AQHaYCdv+HKdg+s0OE+j5sdgQBPcPbERQ2lw
Date: Mon, 19 Feb 2024 07:06:17 +0000
Message-ID: 
 <MN2PR10MB4349049992351787B0E5F83AA0512@MN2PR10MB4349.namprd10.prod.outlook.com>
References: <20240215155009.94493-1-mheyne@amazon.de>
In-Reply-To: <20240215155009.94493-1-mheyne@amazon.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?nldK1WxpqjsuUWq8U5+PmzFHjxwXGp0ZD4Dkz9IxB8d2PXAuZHjyNWgd9Jkd?=
 =?us-ascii?Q?Szsf/Medz2YXHHQ0mmoNupgUOGwkFAva2VFDe+TjZtI7CcVwPUraQzcGCjix?=
 =?us-ascii?Q?JFsirXklrg2enlD0VJvt1ro39U3XjmMl68Gv1OGSco91ZlPvhhdYTL5d2fCs?=
 =?us-ascii?Q?0SKHVkk8cae9Z6iPS7zzcwzuvGsNQLgVCU/xmbPW1Sn+rIs+eBaPzYyQkNjQ?=
 =?us-ascii?Q?DkX9dM3bDd8zknB28oRWafyCmc2NFYuOtclcNPVaNoM+mnm+TDwqU4kncB+q?=
 =?us-ascii?Q?lNSU2zGFsIHU85nKZAgK/R6CIln58pvpx8ZWwKsCU8QKJRxzq9KVOaN+jox2?=
 =?us-ascii?Q?dEadDzXInBxend9sJz2xUGis6zjxdIlRpjaWPlCxwjvvcsqr23B4UJGPyNLE?=
 =?us-ascii?Q?MIHyzk4a6O9MQeYHqCUDZWlVp8gK/lSy/qJ8drXHE0O1KM+Saangk7/ZYNm4?=
 =?us-ascii?Q?6fpD4yPyu1qYgisK3UyhZmauUCfRLpx0sMrjRx5X4ufO00Q/k57sebgPdlwN?=
 =?us-ascii?Q?2fljFt8g5uC9V+88gTVpRcd9D5qaVhYNFVbZdKAr6HideWMQ7PdYGbmUmDI8?=
 =?us-ascii?Q?KSxt567P7xSz6rqqajIYSZrJ4VAsKxxYDeFlKA5sUIKDBrGRy3SI1GD02xhF?=
 =?us-ascii?Q?0X4rtHBkYNqNJ5j1/XAGfK/kmYnxhhM25XZF73YowEvdvYPpeRuUX10Pgueh?=
 =?us-ascii?Q?4FM6dCUBw2l7SUvFiisAWrY8umNIQLPwuc8tQVVyKpJPML3jIFXvwrx+11Pj?=
 =?us-ascii?Q?uAUcozLluyTyASg1BhCPJzRdfvJyswxgFWAfny1VZf+SE/gY61Y9TYl1Vtzn?=
 =?us-ascii?Q?qXAJtuKuuwinHyIsjVFubu4auFQ3NTACqLNBFFcWYORkLHN5IwVsy03ONfQv?=
 =?us-ascii?Q?uQDVNYO5ZKDJMiU0r3KfsOG6U1uA2Dm9/CF/oHvbMFML6Sq889dZLAOUMgJz?=
 =?us-ascii?Q?Ynpymn+1bN94rwTNbXjPeFGJvsJu1OMnDPZPHpMCbQqhBibVonBFhvm/RkeH?=
 =?us-ascii?Q?j44/jUepja40C5GBtrmYLrHp/SvHAKPqfxTa+gT7n89uigreFrFnidnAZoEn?=
 =?us-ascii?Q?LVDHYTrCnrAtBzLcxAf59pfPWYDaKBAh4IFCeaq0m7SL/+XO23IJal7+s2Uu?=
 =?us-ascii?Q?vB0LlUeH81aJyADwk/BAgDu2Hvn9H4XDiL/maw1VX1+VDJRcY9VGWhyfznwg?=
 =?us-ascii?Q?NpHtHiYgeaYanQrngGO7kU39/465tZ2uy2tasDzho/Szo8zS+upjTg2kjP5s?=
 =?us-ascii?Q?Nh5JuAJ1pgtxFUSdYQOCVBuNkHEyXkytkvubR4yFS3WwxspSsCDcnhZjx3x4?=
 =?us-ascii?Q?OfgthUbadnusvBtIEM+gEfBEyCpjt2aigDXfn81xMWuIgdesKunteuq01Nkv?=
 =?us-ascii?Q?18dSTUUN9ZBM0rOxiw1cJB2XOGBJfE8TSVkXEAglGri/fJx4IeHIkOrWRQvX?=
 =?us-ascii?Q?gVJpJBVbYUbiVok7M99OgbaHpag4MLVIZPzodj+V+yZOogB7Umvub/k9oPqh?=
 =?us-ascii?Q?rlOBulORHgZZbVjSVkjyDE2zFrF9c50UpTvZkG1mw+AFPdtqqr0NxLTEqXjK?=
 =?us-ascii?Q?qNKDZi80nZhNWBCrN7T56XatE047RC74pLOhATRRga2sgJZ5ARl9lTzGHyO4?=
 =?us-ascii?Q?kA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-ext4@vger.kernel.org
List-Id: <linux-ext4.vger.kernel.org>
List-Subscribe: <mailto:linux-ext4+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-ext4+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	VsNXOLJg+po6uF5ovMSf/HVrcR048VJ7fShF5UzIrotHATt2SrjlR3M2oWKmWph87RAkSy/r4sUitWGnASF/YACcLgQ3I2Gznhhw+wOGSZCV2bFCX38aGJh2TfkOAjHzwpda7q4KAaGKyZ1fQtqLb/2+qpfzaMQFHthkX3JQT2+0d4wyBpDhWy15WWA56wnPj8jzquNmVqt9yCrM0x1M3xHod16OmBPwCy/sYnLVaZPUUaLACk8tF605UG8Eq3PsOthW3eB303cjJru1e31ziawYiMouPm3z1iQj5rKZMjK92Rc4fc90RR8rl7rtihJX9bJcbRPuEzkI+rKen0zxMlHCYx39eSHPvweXbTEF5Il2aGgAIWrakbS6yzpbI3+kdAzu7h3Q899XIcOdstAI/cxXLslzdptu+AkFCm46aCIwiYsNPtshumyZnz+nYlaIpRGJkbSXVT9XjEaj74ugZy4rXkW651GUKqecETHA9NgVHb1iOE2munmYIL0GEw0OfbD4iYGe79dlFgVySmdtU0QTLPqwQL0jwVW79Fe70gPjSWSUnBV7fVDCIA8KWDq1p96j+Hoq616+zo/pNUbLyOsd29GipfbLOzJi+0ONqtk=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4349.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c842881b-0c72-4ea1-15ca-08dc31194469
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2024 07:06:17.1302
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6udeOLfvfzyVEwF4FyNvT6eidl+pPdjUoGJKKzjsB1i84lSa5A1KiKzqWLm+K6unYSaf/O/v40///U8zp/7J4dS3pV5YFWn8YtvlqztG12w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB4955
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-02-19_04,2024-02-16_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0
 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0 bulkscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2402190052
X-Proofpoint-GUID: W4uyKVQGCsFVZkKxuSijkDwSl--OiS83
X-Proofpoint-ORIG-GUID: W4uyKVQGCsFVZkKxuSijkDwSl--OiS83


-----Original Message-----
From: Maximilian Heyne <mheyne@amazon.de>=20
Sent: Thursday, February 15, 2024 9:20 PM
Cc: ravib@amazon.com; Maximilian Heyne <mheyne@amazon.de>;=20
stable@vger.kernel.org; Theodore Ts'o <tytso@mit.edu>; Andreas Dilger=20
<adilger.kernel@dilger.ca>; Yongqiang Yang <xiaoqiangnk@gmail.com>;=20
linux-ext4@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [External] : [PATCH v2] ext4: fix corruption during on-line resize

> We observed a corruption during on-line resize of a file system that is
> larger than 16 TiB with 4k block size. With having more then 2^32 blocks
> resize_inode is turned off by default by mke2fs. The issue can be
> reproduced on a smaller file system for convenience by explicitly
> turning off resize_inode. An on-line resize across an 8 GiB boundary (the
> size of a meta block group in this setup) then leads to a corruption:
>
>  dev=3D/dev/<some_dev> # should be >=3D 16 GiB
>  mkdir -p /corruption
>  /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)=
)
>  mount -t ext4 $dev /corruption
>
>  dd if=3D/dev/zero bs=3D4096 of=3D/corruption/test count=3D$((2*2**21 - 4=
*2**15))
>  sha1sum /corruption/test
>  # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test
>
>  /sbin/resize2fs $dev $((2*2**21))
>  # drop page cache to force reload the block from disk
>  echo 1 > /proc/sys/vm/drop_caches
>
>  sha1sum /corruption/test
>  # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test
>
> 2^21 =3D 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
> block group and 2^6 are the number of block groups that make a meta
> block group.
>
> The last checksum might be different depending on how the file is laid
> out across the physical blocks. The actual corruption occurs at physical
> block 63*2^15 =3D 2064384 which would be the location of the backup of th=
e
> meta block group's block descriptor. During the on-line resize the file
> system will be converted to meta_bg starting at s_first_meta_bg which is
> 2 in the example - meaning all block groups after 16 GiB. However, in
> ext4_flex_group_add we might add block groups that are not part of the
> first meta block group yet. In the reproducer we achieved this by
> substracting the size of a whole block group from the point where the
> meta block group would start. This must be considered when updating the
> backup block group descriptors to follow the non-meta_bg layout. The fix
> is to add a test whether the group to add is already part of the meta
> block group or not.
>
> Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and =
64-bit file systems")
> Cc: stable@vger.kernel.org

Tested the patch across filesystem of various sizes and blocksizes. The pat=
ch stops
the corruption.

> Signed-off-by: Maximilian Heyne <mheyne@amazon.de>

Tested-by: Srivathsa Dara <srivathsa.d.dara@oracle.com>
Reviewed-by: Srivathsa Dara <srivathsa.d.dara@oracle.com>

> ---
> fs/ext4/resize.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
> index 4d4a5a32e310..3c0d12382e06 100644
> --- a/fs/ext4/resize.c
> +++ b/fs/ext4/resize.c
> @@ -1602,7 +1602,8 @@ static int ext4_flex_group_add(struct super_block *=
sb,
> 		int gdb_num =3D group / EXT4_DESC_PER_BLOCK(sb);
> 		int gdb_num_end =3D ((group + flex_gd->count - 1) /
> 				   EXT4_DESC_PER_BLOCK(sb));
> -		int meta_bg =3D ext4_has_feature_meta_bg(sb);
> +		int meta_bg =3D ext4_has_feature_meta_bg(sb) &&
> +			      gdb_num >=3D le32_to_cpu(es->s_first_meta_bg);
> 		sector_t padding_blocks =3D meta_bg ? 0 : sbi->s_sbh->b_blocknr -
> 					 ext4_group_first_block_no(sb, 0);
>=20
> --=20
> 2.40.1
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879