Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1314668yba; Tue, 2 Apr 2019 06:43:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqwhyhYziHdeVl+MH993yAtTAAHeGcwvGAxW8GqWESI+A4CN3k/70Ak79lZkKRO4D+wcPMr8 X-Received: by 2002:a17:902:5c5:: with SMTP id f63mr66903595plf.64.1554212606279; Tue, 02 Apr 2019 06:43:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554212606; cv=none; d=google.com; s=arc-20160816; b=u2NoGIOOrYvoyrXruGlXZYMdiUpnVHMhzfJwS9Ithe+0p8kK070Qwlv7n4ak+9D/r/ WWfV5GAve+QtFXQ6Qz8nrPqq5x72Wukph0ZojSxb4ba9wByA14iZLUa7Vv/Vl0tRzIg2 FRWKhXSBpFe+8hL02qe2akMF5lLEVVS/fZorkAUfydOxd+cHITg4AvAej/wGAMAR97JY 4RXAgx38PBwVshAkAVLyCbhNXbY0FFpFSCjULheUWSjUN+NV8PxX9Gj/blyIWvnU6rL/ g60SrymWQ9Pl6tolFT+AQWla3HAQNcxU7HH1Zd1w34cHMgkTqkdGtiem94oGkDu14DZy OOuA== 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=jLUN+2UsvojwEH4pOwm3spnIY48cU1L33urWtrNDQ3o=; b=ervSWyzv7ukXLiRJX7VRuQyM+ac3+RDhXvDI9anvEAnfk2CFpe30jv2+hG08zh7re2 hmmj8OahdkHXFGetg0r2ogh8mP+4v+5gOZwnioK5z0IkppPBQjk4TaEkTxy2OoUTMcJt tI6RdzdkZFqDliGNia/MgzpmiYwVeht9lUV0izDjSVRgclm4Mtb1ciYHCt5ghN9yBUnn +32EnfQvFztvs+HvnGIQoxCYuajsmI+XLm4yu/ENEEWP43nMFoZku33z80C7hCWORZB3 j/1OdtHv72gfBFERNsHosVDyOWXOKoH3AenAO6QQWOV4y+AXlOxCq1YxP5wq0d+JGHm1 uYQw== 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 cy1si11665082plb.429.2019.04.02.06.43.11; Tue, 02 Apr 2019 06:43:26 -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 S1731713AbfDBNkk (ORCPT + 99 others); Tue, 2 Apr 2019 09:40:40 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:43600 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731509AbfDBNkL (ORCPT ); Tue, 2 Apr 2019 09:40:11 -0400 Received: from [167.98.27.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hBJe4-0002ol-4i; Tue, 02 Apr 2019 14:40:08 +0100 Received: from ben by deadeye with local (Exim 4.92) (envelope-from ) id 1hBJdy-0004xm-1i; Tue, 02 Apr 2019 14:40:02 +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, Denis Kirjanov , "Theodore Ts'o" Date: Tue, 02 Apr 2019 14:38:28 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 91/99] ext4: avoid kernel warning when writing the superblock to a dead device In-Reply-To: X-SA-Exim-Connect-IP: 167.98.27.226 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.65-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Theodore Ts'o commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream. The xfstests generic/475 test switches the underlying device with dm-error while running a stress test. This results in a large number of file system errors, and since we can't lock the buffer head when marking the superblock dirty in the ext4_grp_locked_error() case, it's possible the superblock to be !buffer_uptodate() without buffer_write_io_error() being true. We need to set buffer_uptodate() before we call mark_buffer_dirty() or this will trigger a WARN_ON. It's safe to do this since the superblock must have been properly read into memory or the mount would have been successful. So if buffer_uptodate() is not set, we can safely assume that this happened due to a failed attempt to write the superblock. Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings --- fs/ext4/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -4712,7 +4712,7 @@ static int ext4_commit_super(struct supe BUFFER_TRACE(sbh, "marking dirty"); ext4_superblock_csum_set(sb); lock_buffer(sbh); - if (buffer_write_io_error(sbh)) { + if (buffer_write_io_error(sbh) || !buffer_uptodate(sbh)) { /* * Oh, dear. A previous attempt to write the * superblock failed. This could happen because the