Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp27844imm; Fri, 21 Sep 2018 17:22:46 -0700 (PDT) X-Google-Smtp-Source: ACcGV63WTQ7J1P3bE5YoBN/VIzynyQ0/LgcAyMlKQD9X2fhALYLbUMra4WeOydbr1MSpg61wsnyu X-Received: by 2002:a65:6086:: with SMTP id t6-v6mr120915pgu.424.1537575766834; Fri, 21 Sep 2018 17:22:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537575766; cv=none; d=google.com; s=arc-20160816; b=hsy4yfZnHSTiZOXFDVCKZ2QF31ovL9rEuKeONygJZEIs0n2p07Yya9Xo+x019Xdj2D gtEqCjMBcpG/43ZWr7L7QKjGYvS2ecKsxoKgs+46HhMAB0rQ+8bj9+nUBwVoTRfTiOhZ TQtE/Eh75BTuGh5Il2nuGMZiKTaW0yPW+3RVemN1z3oG/Wtb/NYbcsx8z86lHpr0VsUZ 6SxuOcuyNdJH3scieqURpYWDnp/6kspyvWnu7eifSqWVF0DEzn2vcz7wmyRfCzQ64wjg oR7S7xE4KucFN5jZIi+sKIHLIzqAaQk/iKyGHk4rP+OQTGWUwut/hwCAaakZkOs6NLkb 9C4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=UdfbzyQwhZiSArMdahOoD2NCDPCCy/tDAOC6VhdL0EY=; b=cMUuDMR/48vjxVjCmD0S8XHHsfukFGpDTCzbYcIdFAH1ls7DoWTS4PCCfyoM0ADj2d o/K1VSF+gJxjo7Mtv2f3rKrBHkgPHdwFqzKPKyfsmu7kb1QoMmp52l/7+z0XHxtiqPoP WuHFaFoJGC0DSWzScP0Iso8Ap4L9BdVBEfiuJCYWtDA/MiRaezVVy4vZVsSj5GxBygw7 R9dFWO1r583/eSH1F6xl6SRS+/XiWG979qa1yz/or4xxja1Y++l6Ylou4y+1a2PcflRo MPst3qpgv96P37/End01GBWZgApNidFyJZcnX39hRL2cKD0mGvQkgNfZ6uLj6U7aldl0 hR2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3-v6si24810385plr.138.2018.09.21.17.22.31; Fri, 21 Sep 2018 17:22:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392119AbeIVGKv (ORCPT + 99 others); Sat, 22 Sep 2018 02:10:51 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:44300 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392075AbeIVGKu (ORCPT ); Sat, 22 Sep 2018 02:10:50 -0400 Received: from [2a02:8011:400e:2:cbab:f00:c93f:614] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1g3Ve0-0008BM-7P; Sat, 22 Sep 2018 01:19:32 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1g3Vdn-0000rh-Tv; Sat, 22 Sep 2018 01:19:19 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Theodore Ts'o" , "Eric Whitney" Date: Sat, 22 Sep 2018 01:15:42 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 25/63] ext4: fix check to prevent initializing reserved inodes In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:cbab:f00:c93f:614 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.58-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit 5012284700775a4e6e3fbe7eac4c543c4874b559 upstream. Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is valid" will complain if block group zero does not have the EXT4_BG_INODE_ZEROED flag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system: mkfs.ext4 /dev/vdc mount -o ro /dev/vdc /vdc mount -o remount,rw /dev/vdc Instead, when initializing the inode table for block group zero, test to make sure that itable_unused count is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared. This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case. Fixes: 8844618d8aa7 ("ext4: only look at the bg_flags field if it is valid") Reported-by: Eric Whitney Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- fs/ext4/ialloc.c | 5 ++++- fs/ext4/super.c | 8 +------- 2 files changed, 5 insertions(+), 8 deletions(-) --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -1289,7 +1289,10 @@ int ext4_init_inode_table(struct super_b ext4_itable_unused_count(sb, gdp)), sbi->s_inodes_per_block); - if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group)) { + if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group) || + ((group == 0) && ((EXT4_INODES_PER_GROUP(sb) - + ext4_itable_unused_count(sb, gdp)) < + EXT4_FIRST_INO(sb)))) { ext4_error(sb, "Something is wrong with group %u: " "used itable blocks: %d; " "itable unused count: %u", --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3088,14 +3088,8 @@ static ext4_group_t ext4_has_uninit_itab if (!gdp) continue; - if (gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED)) - continue; - if (group != 0) + if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED))) break; - ext4_error(sb, "Inode table for bg 0 marked as " - "needing zeroing"); - if (sb->s_flags & MS_RDONLY) - return ngroups; } return group;