From patchwork Tue Sep 4 02:25:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 966170 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=thunk.org header.i=@thunk.org header.b="mnPRsQNm"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 424nXQ335kz9sCf for ; Wed, 5 Sep 2018 12:22:14 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726241AbeIEGuE (ORCPT ); Wed, 5 Sep 2018 02:50:04 -0400 Received: from imap.thunk.org ([74.207.234.97]:51266 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726215AbeIEGuD (ORCPT ); Wed, 5 Sep 2018 02:50:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CcFb+L9vMxI8hgGhJ6jx7L99tvpsncOtla5VO6D3yuc=; b=mnPRsQNmWmrve2fBVgwDsppCeg D4lAS14TxdVWdmcEFI3azIbPMeErZ0tZUcL1uOmHaXpL30aKrCwTn2dFNwFQWjSgjABHSeXD8Y2Ii Mirblr0gYbw9RvhlYksu3a/0XS5DtPHtZdxDNWWiIn6os41nTyALm1CaAMh95JapG1VI=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fxNSK-0007JD-DO; Wed, 05 Sep 2018 02:22:08 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 350B67A4B95; Mon, 3 Sep 2018 22:25:56 -0400 (EDT) From: Theodore Ts'o To: Ext4 Developers List Cc: Torsten Hilbrich , Theodore Ts'o , stable@vger.kernel.org Subject: [PATCH 1/2] ext4: fix online resize's handling of a too-small final block group Date: Mon, 3 Sep 2018 22:25:45 -0400 Message-Id: <20180904022546.16351-1-tytso@mit.edu> X-Mailer: git-send-email 2.18.0.rc0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group. This problem can be triggered with the following reproducer: umount /mnt mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \ -E resize=1073741824 /tmp/foo.img 128M mount /tmp/foo.img /mnt truncate --size 1708M /tmp/foo.img resize2fs /dev/loop0 295400 umount /mnt e2fsck -fy /tmp/foo.img Reported-by: Torsten Hilbrich Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org --- fs/ext4/resize.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index e5fb38451a73..33655a6eff4d 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1986,6 +1986,26 @@ int ext4_resize_fs(struct super_block *sb, ext4_fsblk_t n_blocks_count) } } + /* + * Make sure the last group has enough space so that it's + * guaranteed to have enough space for all metadata blocks + * that it might need to hold. (We might not need to store + * the inode table blocks in the last block group, but there + * will be cases where this might be needed.) + */ + if ((ext4_group_first_block_no(sb, n_group) + + ext4_group_overhead_blocks(sb, n_group) + 2 + + sbi->s_itb_per_group + sbi->s_cluster_ratio) >= n_blocks_count) { + n_blocks_count = ext4_group_first_block_no(sb, n_group); + n_group--; + n_blocks_count_retry = 0; + if (resize_inode) { + iput(resize_inode); + resize_inode = NULL; + } + goto retry; + } + /* extend the last group */ if (n_group == o_group) add = n_blocks_count - o_blocks_count; From patchwork Tue Sep 4 02:25:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 966171 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=thunk.org header.i=@thunk.org header.b="s5ZpIn/h"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 424nXf0zqRz9s3Z for ; Wed, 5 Sep 2018 12:22:26 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726090AbeIEGuD (ORCPT ); Wed, 5 Sep 2018 02:50:03 -0400 Received: from imap.thunk.org ([74.207.234.97]:51264 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725825AbeIEGuD (ORCPT ); Wed, 5 Sep 2018 02:50:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6DPT4DfA9RisrrEQpRhe0IJWvegqdHYWiyIw5I0wxHA=; b=s5ZpIn/hfmSGMABsh9f/1ApqS2 rl9Er8vHWwgULTCMsBnz/Qo4DATuOF7f90TD8wvNCosL4klcA81Gx0n4kWJkwBVk+F7ixKcenEZGN daUsVn4LA9/FJ6k6+io5LkGpPyVRNibRjUE6kSA8SEYoqm5lBmTaT1/72OMaHbe19TQM=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fxNSK-0007JI-K0; Wed, 05 Sep 2018 02:22:08 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id C89F07A4B97; Mon, 3 Sep 2018 22:25:57 -0400 (EDT) From: Theodore Ts'o To: Ext4 Developers List Cc: Torsten Hilbrich , Theodore Ts'o , stable@vger.kernel.org Subject: [PATCH 2/2] ext4: fix online resizing for bigalloc file systems with a 1k block size Date: Mon, 3 Sep 2018 22:25:46 -0400 Message-Id: <20180904022546.16351-2-tytso@mit.edu> X-Mailer: git-send-email 2.18.0.rc0 In-Reply-To: <20180904022546.16351-1-tytso@mit.edu> References: <20180904022546.16351-1-tytso@mit.edu> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org An online resize of a file system with the bigalloc feature enabled and a 1k block size would be refused since ext4_resize_begin() did not understand s_first_data_block is 0 for all bigalloc file systems, even when the block size is 1k. Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org --- 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 33655a6eff4d..ebbc663d0798 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -19,6 +19,7 @@ int ext4_resize_begin(struct super_block *sb) { + struct ext4_sb_info *sbi = EXT4_SB(sb); int ret = 0; if (!capable(CAP_SYS_RESOURCE)) @@ -29,7 +30,7 @@ int ext4_resize_begin(struct super_block *sb) * because the user tools have no way of handling this. Probably a * bad time to do it anyways. */ - if (EXT4_SB(sb)->s_sbh->b_blocknr != + if (EXT4_B2C(sbi, sbi->s_sbh->b_blocknr) != le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block)) { ext4_warning(sb, "won't resize using backup superblock at %llu", (unsigned long long)EXT4_SB(sb)->s_sbh->b_blocknr);