Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3334218imu; Sun, 11 Nov 2018 12:36:24 -0800 (PST) X-Google-Smtp-Source: AJdET5eqNg3INn0QhDNUCVrWWmXIgo8zCqndz8vh3eiUesiUyku5SglFT2UIW24WZXhXuvyo+HVM X-Received: by 2002:a62:a5b:: with SMTP id s88-v6mr18121787pfi.136.1541968584880; Sun, 11 Nov 2018 12:36:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968584; cv=none; d=google.com; s=arc-20160816; b=Vdi3haO2MUhY8rAViPDG3AvuvGPosVRIbXj5ez8XborwB9KVogzOWIUrNNYldxBl+S UeNh8hyAI0N16uEg7XJB65myyI5agwaDfAPjnouJpBiveZt1lT8ym/i2pQwmSDvXDomQ YohG12fIqEFdCjmOuYhLvKEFiZLPBcEsAvxW7tKFxWM/2uesGklWFVtIWqv2LoIRzIay ko375gfuDmOX5fqRP5FsvjYAM0p58igoA0DUiGxo8XoW1jNkYjxGsHVV/TJebMkC3ibu Ama2WWY3nSqXy4O1wr6MF+ke3roBfNVXkgH9SDu8QoZwTDZQ1bBy1u2abba9EjxFpdrh P7dg== 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=OfM0CTQKm485qTe5uZJBl0b4b/IZt7iJfx0gcLnUN2A=; b=oEKSRyHkTsD7a79FA/JhnO3czfWr1rz9AI5mErZsuE8xNYTLL9jLOxNPY2VY06qIbp ww6UMH87Nkw1vQLwlmnQ0gMMYBfwaNxqG4dxqHLeSylOzGQ8Ywg2ZXVrrN6r94ZRE4M4 6otiS4wL7l6SuiAgT9iSNWgKaf29TPy5jHmee1/n19ng3ZboXESkRSE+tUYQx1FDHZvc 1kjP+l+3SY8X3FxjgK2Ib51djN7a0kkMScO0n5cCMYfNcuJRLsXuv+GoR4I1OxGqgd/T sb8HztSNA0TwrI73vjMZk/amP72KtbYXvmYNyl4kMJzr9BD7pDUAnpeP6nZ5drCmOVym +YVQ== 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 x9si13935379pgh.12.2018.11.11.12.36.09; Sun, 11 Nov 2018 12:36:24 -0800 (PST) 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 S1730390AbeKLGYx (ORCPT + 99 others); Mon, 12 Nov 2018 01:24:53 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49918 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730201AbeKLFsN (ORCPT ); Mon, 12 Nov 2018 00:48:13 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvsY-0000l6-TD; Sun, 11 Nov 2018 19:58:43 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsW-0001ik-9e; Sun, 11 Nov 2018 19:58:40 +0000 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" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 247/366] ext4: check for allocation block validity with block group locked In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef upstream. With commit 044e6e3d74a3: "ext4: don't update checksum of new initialized bitmaps" the buffer valid bit will get set without actually setting up the checksum for the allocation bitmap, since the checksum will get calculated once we actually allocate an inode or block. If we are doing this, then we need to (re-)check the verified bit after we take the block group lock. Otherwise, we could race with another process reading and verifying the bitmap, which would then complain about the checksum being invalid. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -377,6 +377,8 @@ static void ext4_validate_block_bitmap(s return; ext4_lock_group(sb, block_group); + if (buffer_verified(bh)) + goto verified; blk = ext4_valid_block_bitmap(sb, desc, block_group, bh); if (unlikely(blk != 0)) { ext4_unlock_group(sb, block_group); @@ -399,6 +401,7 @@ static void ext4_validate_block_bitmap(s return; } set_buffer_verified(bh); +verified: ext4_unlock_group(sb, block_group); } --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -166,6 +166,8 @@ ext4_read_inode_bitmap(struct super_bloc verify: ext4_lock_group(sb, block_group); + if (buffer_verified(bh)) + goto verified; if (!buffer_verified(bh) && !ext4_inode_bitmap_csum_verify(sb, block_group, desc, bh, EXT4_INODES_PER_GROUP(sb) / 8)) { @@ -183,8 +185,9 @@ verify: set_bit(EXT4_GROUP_INFO_IBITMAP_CORRUPT_BIT, &grp->bb_state); return NULL; } - ext4_unlock_group(sb, block_group); set_buffer_verified(bh); +verified: + ext4_unlock_group(sb, block_group); return bh; }