Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3312445imu; Sun, 11 Nov 2018 12:08:41 -0800 (PST) X-Google-Smtp-Source: AJdET5evGjUhrYODIhi7SM0GC+ytx+P8FG8tVgzTloODxOc132BUE+uiRTr8KODxiTewjbsBF9qH X-Received: by 2002:a62:5d49:: with SMTP id r70-v6mr17629349pfb.123.1541966921505; Sun, 11 Nov 2018 12:08:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541966921; cv=none; d=google.com; s=arc-20160816; b=ROWorknYNa0WvGhsHobIDjZRo7EfcF4x8zTHFiVnbijjsToYH1+DPWlFoxWhkpcQSr Am3BUasNLUKODlMdW0UhqEsSnk1DsfUKf8ZG0CnwsA13bnnt4XLgBNX/DHv+jODuUn2B c4avQEIt/ydk/6UzET8Oiuss+macurpf6NSKPZ5++qIgQ6bPZ3SwGKHGxePdinP5GcKl IS/5PNDTkFCpoecSvUzQamJo2mRdR+5DvkiU8NPTMtZlgOBURyb1Hp92wIF5dN4ASKdX 5b1ntilEorwIYO6RYTDEBHxmy5BlHvlKLPTt85oUnpRypIPxdkBPfTy4YlNxOSOjwzzE qfQQ== 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=uDn+7zKMOctWlQO67fT3MRM6PDYEoParvSXOSjiUKJY=; b=F0b506B9wFF07YbPAI5X013z3AWthpzOtyO8C7vr2kiIoNk1UFxUlmWMQV7C/19MeB lD/UxwXdSoUSNaIdiKa/iE3lnnzm0pwYrJgvek/I4RnGV4WExFiX8mEXIJ0apHme/ssA VwmV+xa5A2vFo+4si+ZG5vZThphjx/oJk/hGjXhGuR29wVhrwinyzMETl3Tie6lS+YHw xzUB7IcxbU9kGVfS4XMeAwhoZKykGTEUx380iku9dum1mf1hkPkaaGDSBv7t61A1zCvI MYEyKTgB77bMNU/DwbCqb4HxZ1q727vmXqwebxHHcmhYI72aYaTb1p6hL09bQ88Z3/Gs vc9g== 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 x5si13440361pga.440.2018.11.11.12.08.26; Sun, 11 Nov 2018 12:08:41 -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 S1731611AbeKLF5e (ORCPT + 99 others); Mon, 12 Nov 2018 00:57:34 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:52240 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730964AbeKLF5e (ORCPT ); Mon, 12 Nov 2018 00:57:34 -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 1gLvsv-0000lF-4H; Sun, 11 Nov 2018 19:59:05 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsV-0001f5-6H; Sun, 11 Nov 2018 19:58:39 +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" , "Jon Derrick" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 217/366] ext4: check superblock mapped prior to committing 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: Jon Derrick commit a17712c8e4be4fa5404d20e9cd3b2b21eae7bc56 upstream. This patch attempts to close a hole leading to a BUG seen with hot removals during writes [1]. A block device (NVME namespace in this test case) is formatted to EXT4 without partitions. It's mounted and write I/O is run to a file, then the device is hot removed from the slot. The superblock attempts to be written to the drive which is no longer present. The typical chain of events leading to the BUG: ext4_commit_super() __sync_dirty_buffer() submit_bh() submit_bh_wbc() BUG_ON(!buffer_mapped(bh)); This fix checks for the superblock's buffer head being mapped prior to syncing. [1] https://www.spinics.net/lists/linux-ext4/msg56527.html Signed-off-by: Jon Derrick Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings --- fs/ext4/super.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -4653,6 +4653,14 @@ static int ext4_commit_super(struct supe if (!sbh || block_device_ejected(sb)) return error; + + /* + * The superblock bh should be mapped, but it might not be if the + * device was hot-removed. Not much we can do but fail the I/O. + */ + if (!buffer_mapped(sbh)) + return error; + /* * If the file system is mounted read-only, don't update the * superblock write time. This avoids updating the superblock