From patchwork Thu Jul 4 18:16:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 1127662 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45fmQq23jJz9sPB; Fri, 5 Jul 2019 04:17:07 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1hj6Hz-0002sJ-Be; Thu, 04 Jul 2019 18:16:59 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1hj6Hx-0002sD-6U for kernel-team@lists.ubuntu.com; Thu, 04 Jul 2019 18:16:57 +0000 Received: from mail-qt1-f197.google.com ([209.85.160.197]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hj6Hw-0006NY-P6 for kernel-team@lists.ubuntu.com; Thu, 04 Jul 2019 18:16:56 +0000 Received: by mail-qt1-f197.google.com with SMTP id h47so7287738qtc.20 for ; Thu, 04 Jul 2019 11:16:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=JduOhxEou9HGUcM2UsnhLaeqEYk+Oy4U4ESk3nTenO4=; b=rS8yCjk7aNgLkdXtLnrUQOBurateAZ9kS76yyDONfMexF4Vw6RcvTygyR3Q0GmzkAa j3EKk9AYokqFEHBWEcI5dRWlKxM3FpilAoaL1BowI6PS7FeJ95egaHh7aspi6jvcXAi3 bXyueNSncg+lXj/s3aDMwIsMj+jzqFKnLZg1v527+YUi0qRonW0gUpFoU3033AP53w/e EuUYxM7zeiaWM2HX873EAck/1M+Ii+fML1I6RtJ2AkNFhyGBlbs1ZReViZ70pOYfMb2/ nb1YBZtHS9dKYryvqNncmgiirDlYlc9HX/EniYeXMp0LbnrFGs3vDoYL2I4wCWImxfQ9 Hy+w== X-Gm-Message-State: APjAAAXDPQB5HsL9IjU40+0JqtqWddU+CoGpRPPVYUxH+hsaazokByFf vocvDaFL/en5IbUnJBlZHokBwKT6ER+Fowo8oEa4vxRKD3oNPTas3sX+bKcwNnkRGUVRXV3nfGx jpNZIs7ulHjcrDXkjo5YIZjOXbEJMlubSOY5ub+lt X-Received: by 2002:ac8:2c35:: with SMTP id d50mr35036401qta.313.1562264213380; Thu, 04 Jul 2019 11:16:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxKVHZe8C3JaBoleq6D2v25YzmbUpnXRp0VAn6mBiSFKb2D+uJ/qIaJGBhrBeGd5V/K0WHDfg== X-Received: by 2002:ac8:2c35:: with SMTP id d50mr35036375qta.313.1562264212719; Thu, 04 Jul 2019 11:16:52 -0700 (PDT) Received: from localhost.localdomain ([2804:18:11:5288:80e1:f148:98fb:8bed]) by smtp.gmail.com with ESMTPSA id d23sm2528156qkk.46.2019.07.04.11.16.50 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 04 Jul 2019 11:16:51 -0700 (PDT) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [x/azure,c/azure][PATCH] ext4: fix crash during online resizing Date: Thu, 4 Jul 2019 15:16:45 -0300 Message-Id: <20190704181645.16067-1-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Jan Kara BugLink: http://bugs.launchpad.net/bugs/1835322 When computing maximum size of filesystem possible with given number of group descriptor blocks, we forget to include s_first_data_block into the number of blocks. Thus for filesystems with non-zero s_first_data_block it can happen that computed maximum filesystem size is actually lower than current filesystem size which confuses the code and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on flex_gd->count == 0. The problem can be reproduced like: truncate -s 100g /tmp/image mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs /dev/loop0 262145 resize2fs /dev/loop0 300000 Fix the problem by properly including s_first_data_block into the computed number of filesystem blocks. Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..." Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org (cherry picked from commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1) Signed-off-by: Marcelo Henrique Cerri Acked-by: Thadeu Lima de Souza Cascardo Acked-by: Tyler Hicks --- 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 c38f9e838aef..b7809d16a5d4 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1957,7 +1957,8 @@ int ext4_resize_fs(struct super_block *sb, ext4_fsblk_t n_blocks_count) le16_to_cpu(es->s_reserved_gdt_blocks); n_group = n_desc_blocks * EXT4_DESC_PER_BLOCK(sb); n_blocks_count = (ext4_fsblk_t)n_group * - EXT4_BLOCKS_PER_GROUP(sb); + EXT4_BLOCKS_PER_GROUP(sb) + + le32_to_cpu(es->s_first_data_block); n_group--; /* set to last group number */ }