Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp571771imw; Thu, 14 Jul 2022 06:57:18 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uFR45val2Q49JEv2eYULH8OYQ0Wjg8CFwIqhpz9WbBGw6aPIcPNvgBSAz2adNtx4IrMS1f X-Received: by 2002:a63:a749:0:b0:40c:57e0:86c0 with SMTP id w9-20020a63a749000000b0040c57e086c0mr7749869pgo.265.1657807038119; Thu, 14 Jul 2022 06:57:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657807038; cv=none; d=google.com; s=arc-20160816; b=Z9Te5EMtlsNs4YeTKhcoXleYEqKdlds/5aoNV5kY/5rXx0qNXEo43As+xTkGBXC+7s +6GCNdQv6kqWapHZ01s+8XwwHifU4Qh3CVbyN5/O+YBX4G530d/uL9gzmb4GYrZ7jH/H 41HW1fLHB4ITgv2MHcVwwn7K8G5mpoP0DuE4svOqn+1ypbXecrg84zb1+QMUrccGmitM zsitJqFK2fOfXZGLmcvnv6zNezrB5j/3KtxVYnOQvNnEvkdFPxWRgswzgnB8Tq4YxmHP mbjD/4w15VBw13P1HnqVkgieh48V1hvlohO8U76yWPhteFe58pfqBqH4SMOBg0U6k9Bq bbJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=HZeBCCSfbfinkenJK3/a6Cgbl51IpF034A7Oj8/JZfU=; b=THdC75MSVmjTgy0VtZH7NzlwoEU/5K0VEWxn1Lf5t3RkHc71V8hoI0XAMNz1daPO80 APL44IHN5XXtwQtFq1rfoYNuugTEPo21VT4KPbdOREvnvDgEkUEpzFjGbO0T2GAKLtL3 u35r0jGe8T3U/wENQVW+SnfttjAHFq3EQO7j1EUIUrbQuG2reE06Asrf6QX1Zj0Roq/4 FWJ6SYWsZNJz40eaytkaYKqn/hfmYBzacHBly2r4LquzSMT4Js39tibRWYzwS5Ubl2eN bzdBTNRXtLYL3eMJhPTAHg3Nr2dz3Jl/s/S5vWkK2QjXdMV6Az403rithF6+KoiTJCub sCpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Ia71PGoq; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=fkeVrjtl; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v3-20020a170902b7c300b0015d29ba7843si755014plz.262.2022.07.14.06.57.01; Thu, 14 Jul 2022 06:57:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=Ia71PGoq; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=fkeVrjtl; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239917AbiGNN4X (ORCPT + 99 others); Thu, 14 Jul 2022 09:56:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240197AbiGNNzn (ORCPT ); Thu, 14 Jul 2022 09:55:43 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71253691E6 for ; Thu, 14 Jul 2022 06:52:33 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 146691FAB3; Thu, 14 Jul 2022 13:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1657806752; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HZeBCCSfbfinkenJK3/a6Cgbl51IpF034A7Oj8/JZfU=; b=Ia71PGoqcVvMonuTWErbYeHmd2OXH4Nfm2SKEaSY9b6bdsZSxVIi6cQbNBNMLXGA1Nonmu 8+184j9PNFaJrRmxX0O7IdYCA1+8t8bCG0AtLaEOkp/wt5EtQVf7tX6E6PnLzNAFg+7PXJ BF9FSog6RqtEV8j8PA74+ChTEVtA4uI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1657806752; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HZeBCCSfbfinkenJK3/a6Cgbl51IpF034A7Oj8/JZfU=; b=fkeVrjtlym05Pc/98bZ0rh9HRsy3BQ6UOLh4HxgavUIx9gbpq2Y008aNpAlsdJ9sOiC/5/ oKgQmXJ6lWD5+1Dw== Received: from quack3.suse.cz (unknown [10.100.224.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 051C82C141; Thu, 14 Jul 2022 13:52:32 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id A36BAA0659; Thu, 14 Jul 2022 15:52:31 +0200 (CEST) Date: Thu, 14 Jul 2022 15:52:31 +0200 From: Jan Kara To: "Kiselev, Oleg" Cc: "linux-ext4@vger.kernel.org" , Theodore Ts'o Subject: Re: [PATCH 2/2] ext4: avoid resizing to a partial cluster size Message-ID: <20220714135231.aull3vo44yfa6azg@quack3> References: <9CDF7393-5645-4E8A-9D68-01CF7F4C4955@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CDF7393-5645-4E8A-9D68-01CF7F4C4955@amazon.com> X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_SOFTFAIL, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu 30-06-22 02:17:22, Kiselev, Oleg wrote: > This patch avoids an attempt to resize the filesystem to an > unaligned cluster boundary. An online resize to a size that is not > integral to cluster size results in the last iteration attempting to > grow the fs by a negative amount, which trips a BUG_ON and leaves the fs > with a corrupted in-memory superblock. > > Signed-off-by: Oleg Kiselev > --- ... > @@ -1624,7 +1624,8 @@ static int ext4_setup_next_flex_gd(struct super_block *sb, > > o_blocks_count = ext4_blocks_count(es); > > - if (o_blocks_count == n_blocks_count) > + if ((o_blocks_count == n_blocks_count) || > + ((n_blocks_count - o_blocks_count) < sbi->s_cluster_ratio)) > return 0; So why do you silently do nothing with unaligned size? I'd expect we should catch this condition already in ext4_resize_fs() and return EINVAL in that case... Also this code does something else than what the commit log says. You actually check whether there are less than one cluster worth of blocks instead of checking whether n_blocks_count is properly aligned. Why is that enough? Honza -- Jan Kara SUSE Labs, CR