Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2400710imu; Thu, 24 Jan 2019 12:07:16 -0800 (PST) X-Google-Smtp-Source: ALg8bN6LztUlWWTkUwMR1ofitzrjWZqFwPBbqEEX4HonphgRgfFvkPiVA1wY01OMNVdmq2/EF8b0 X-Received: by 2002:a63:6486:: with SMTP id y128mr7248836pgb.18.1548360436902; Thu, 24 Jan 2019 12:07:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548360436; cv=none; d=google.com; s=arc-20160816; b=dJ/OrxOm/7MDL2W+PszpT3IvnGeFG4UDfeQJVWlxEj1bIfE8pETmZHzAZUftfJb0B7 g8a5klHfJUJab8JzWOcvodTqtTM1ZRMpcefs5XvrWLbEjw7iCEFwk/sedLJEJug8YZ5a QxBmfzKv5gfmUjdqzVp1Z8A6kyVx8zL+tGe2emkv6YhFGy4lVLEwnfBtL/K54kpv0wrB rqo1ELLNuOcYZJRbvX48+/7YtPx/GBLKlTXDeRuCy+dULB5LdpAZPDgpfxIjbJS71WRJ +fAVmexM8bntJp4arpSojJ0LUyKbRABuV9Kfgsbm5ugBEAha5ymyKeEPUuF5KicpH/3K sohQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=yOjD8voEmjlQytDhBBRYqlfGcP04yELHzeW9WvinlJA=; b=lAYauPAMPvVy0GpkbICogRjKt2XXSmplThMCNZ1CgLhiGvmR2eccv7xuRx0FXUxNJ9 u5ZP+G1dBv7Z0hEJ+Ve5Kwsw6v2X4F4VE0eD/iGhHw6ajrCoUWrnCUjql0q1Q18AY4nK MS3YwqUcmSq3IuX9r46nWmMz5SBrgWGhlxZev4r5QuTFGnzyAz2AyL3M9GIqUG3GJvR4 KZq9LnpPTpreQ+wD9RPtBfUDXWg4YXzYNz6vJI/TOgCGjvvEGpUGKHYg3Uigyy4ZjwWB 22zbo/+CBE8ydB3Xikbkujs3YW/DIskXCrziC1O5PO2NY/jMDMgPtxTVibeyEO4HDhG3 RR1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=l3Kg4H20; 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 q70si23760107pgq.526.2019.01.24.12.07.01; Thu, 24 Jan 2019 12:07:16 -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; dkim=pass header.i=@kernel.org header.s=default header.b=l3Kg4H20; 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 S1730955AbfAXTaZ (ORCPT + 99 others); Thu, 24 Jan 2019 14:30:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:57830 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731395AbfAXTaW (ORCPT ); Thu, 24 Jan 2019 14:30:22 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4214D218D4; Thu, 24 Jan 2019 19:30:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548358221; bh=WNsXXopDXfMqKRGsGv7dTct0okCyg9NubWjQ0TacW5g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l3Kg4H20LeLQTidFRx5BnsZB2OWooULMo0cA5G16hqwiCVi0GV9/R6WztUnojpqQ1 ZDW8XUri/EX+LiBYIkB+UcsSKz4FUjrDWLRMJg2fmfg247jAKnrTxC25XLtA0dvUhv eeX3naGMv0mvsSwFtuxRbqr5swRa2ymfvfOj84bI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , Jan Kara , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 4.9 36/39] mm/page-writeback.c: dont break integrity writeback on ->writepage() error Date: Thu, 24 Jan 2019 20:20:39 +0100 Message-Id: <20190124190449.613526935@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190124190448.232316246@linuxfoundation.org> References: <20190124190448.232316246@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit 3fa750dcf29e8606e3969d13d8e188cc1c0f511d ] write_cache_pages() is used in both background and integrity writeback scenarios by various filesystems. Background writeback is mostly concerned with cleaning a certain number of dirty pages based on various mm heuristics. It may not write the full set of dirty pages or wait for I/O to complete. Integrity writeback is responsible for persisting a set of dirty pages before the writeback job completes. For example, an fsync() call must perform integrity writeback to ensure data is on disk before the call returns. write_cache_pages() unconditionally breaks out of its processing loop in the event of a ->writepage() error. This is fine for background writeback, which had no strict requirements and will eventually come around again. This can cause problems for integrity writeback on filesystems that might need to clean up state associated with failed page writeouts. For example, XFS performs internal delayed allocation accounting before returning a ->writepage() error, where applicable. If the current writeback happens to be associated with an unmount and write_cache_pages() completes the writeback prematurely due to error, the filesystem is unmounted in an inconsistent state if dirty+delalloc pages still exist. To handle this problem, update write_cache_pages() to always process the full set of pages for integrity writeback regardless of ->writepage() errors. Save the first encountered error and return it to the caller once complete. This facilitates XFS (or any other fs that expects integrity writeback to process the entire set of dirty pages) to clean up its internal state completely in the event of persistent mapping errors. Background writeback continues to exit on the first error encountered. [akpm@linux-foundation.org: fix typo in comment] Link: http://lkml.kernel.org/r/20181116134304.32440-1-bfoster@redhat.com Signed-off-by: Brian Foster Reviewed-by: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/page-writeback.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/mm/page-writeback.c b/mm/page-writeback.c index 807236aed275..281a46aeae61 100644 --- a/mm/page-writeback.c +++ b/mm/page-writeback.c @@ -2148,6 +2148,7 @@ int write_cache_pages(struct address_space *mapping, { int ret = 0; int done = 0; + int error; struct pagevec pvec; int nr_pages; pgoff_t uninitialized_var(writeback_index); @@ -2244,25 +2245,31 @@ continue_unlock: goto continue_unlock; trace_wbc_writepage(wbc, inode_to_bdi(mapping->host)); - ret = (*writepage)(page, wbc, data); - if (unlikely(ret)) { - if (ret == AOP_WRITEPAGE_ACTIVATE) { + error = (*writepage)(page, wbc, data); + if (unlikely(error)) { + /* + * Handle errors according to the type of + * writeback. There's no need to continue for + * background writeback. Just push done_index + * past this page so media errors won't choke + * writeout for the entire file. For integrity + * writeback, we must process the entire dirty + * set regardless of errors because the fs may + * still have state to clear for each page. In + * that case we continue processing and return + * the first error. + */ + if (error == AOP_WRITEPAGE_ACTIVATE) { unlock_page(page); - ret = 0; - } else { - /* - * done_index is set past this page, - * so media errors will not choke - * background writeout for the entire - * file. This has consequences for - * range_cyclic semantics (ie. it may - * not be suitable for data integrity - * writeout). - */ + error = 0; + } else if (wbc->sync_mode != WB_SYNC_ALL) { + ret = error; done_index = page->index + 1; done = 1; break; } + if (!ret) + ret = error; } /* -- 2.19.1