Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp634368img; Fri, 22 Mar 2019 05:35:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZSXyb4YamezZHkQVBtuVPiheBrX4cPVAD24bfwuopCRrIzf0uOHNHObAjaTPH/t5laseD X-Received: by 2002:a63:c00a:: with SMTP id h10mr8738342pgg.272.1553258146823; Fri, 22 Mar 2019 05:35:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553258146; cv=none; d=google.com; s=arc-20160816; b=a4BeVTxK6s93/wgmOJYIsYFbTzbOVJy+39615wjMTpuCkGIJ4jEQlcWJ6F3poSkXUb qUxHGWXdthyNpW1jJihwDSVpq40c4hE6ZNipCC14YQ9h94aDQEI7uzSbg5HtlXzpI1Dw YD78qhBOlBwlVOwkAcPv1lVCjkMi21xMkRegLeAKrQJyJTXt1Qa81cn7TFYp9HL2XfJz dU0tMGPlremy0NSOcnGa2aC3Ot9BIJbARC58HKx5IcfOZLoqAEdjdjTUhpzHb0NuXbHs IUEeYIsRS4A0/S2BgRg2r8CPsm9PX4yuGIV0Wl3np/QbqtK9JiYAXWsG0klU+ZUB4WCK TFvA== 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=1c0DQdExKiOwMrmvyWMjZTXhmC0tQt5n+BNwmVuOfQg=; b=Cs+7nh5T92h5DizdV3Zs0e74Dd2Kf+DNEEq7+oceeM9x0FbQv2Jo7QD4YA+tBGIC73 g35CqHOL5lCzZmGEUq6/lLq4sL57uorXTMos2mVKUcg+OCA55D7sxKhdHh7DBl8cXQxF tQ0e26QILwqIiZKCtmlWtIuQbfkX8eI6oIXSzE0GOfDwEOiOoswuOZZT6yY2cICbRRzY OrL0f6+dSK1BeOsKxtwlQp+H0m9934f/ibcVxP2ELyHsWD3f+y5f9zWzCcj1m0ofrbLW jAw/Bnf0Is+aUKe6XKxb3ID7oZVTYFKoEiQGp27KHUdoibfX5FvEpC9Gvqh36o8z0twT SPlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UbAwpCgt; 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 y8si6455539pgv.340.2019.03.22.05.35.31; Fri, 22 Mar 2019 05:35: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; dkim=pass header.i=@kernel.org header.s=default header.b=UbAwpCgt; 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 S2389716AbfCVMOW (ORCPT + 99 others); Fri, 22 Mar 2019 08:14:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:52526 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389275AbfCVMOR (ORCPT ); Fri, 22 Mar 2019 08:14:17 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.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 7F67E2083D; Fri, 22 Mar 2019 12:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553256856; bh=EUTQYl1C+28xN5VV3/tEDJEvWiCe25V60rs5vj9EMYM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UbAwpCgtZqhPN1UG22YIi2p+CO4f/82KjFIFw0IQQT2qgkxcWKyoAxP92F2qIw8LQ DlgBEDJ++L0UI3ktyXqiIMleHS4AAM+iVsT2fa+5GrvGknNwpxCxnXLulETyMU/T9v eCQLZ3xafm0Jc+9FhCgx0a8sctgkJP2c8U55s4M8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Piotr Balcer , Dan Williams , Jan Kara , Matthew Wilcox Subject: [PATCH 5.0 025/238] dax: Flush partial PMDs correctly Date: Fri, 22 Mar 2019 12:14:04 +0100 Message-Id: <20190322111259.667020813@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190322111258.383569278@linuxfoundation.org> References: <20190322111258.383569278@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 5.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthew Wilcox commit e4b3448bc346fedf36db64124a664a959995b085 upstream. The radix tree would rewind the index in an iterator to the lowest index of a multi-slot entry. The XArray iterators instead leave the index unchanged, but I overlooked that when converting DAX from the radix tree to the XArray. Adjust the index that we use for flushing to the start of the PMD range. Fixes: c1901cd33cf4 ("page cache: Convert find_get_entries_tag to XArray") Cc: Reported-by: Piotr Balcer Tested-by: Dan Williams Reviewed-by: Jan Kara Signed-off-by: Matthew Wilcox Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman --- fs/dax.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) --- a/fs/dax.c +++ b/fs/dax.c @@ -843,9 +843,8 @@ unlock_pte: static int dax_writeback_one(struct xa_state *xas, struct dax_device *dax_dev, struct address_space *mapping, void *entry) { - unsigned long pfn; + unsigned long pfn, index, count; long ret = 0; - size_t size; /* * A page got tagged dirty in DAX mapping? Something is seriously @@ -894,17 +893,18 @@ static int dax_writeback_one(struct xa_s xas_unlock_irq(xas); /* - * Even if dax_writeback_mapping_range() was given a wbc->range_start - * in the middle of a PMD, the 'index' we are given will be aligned to - * the start index of the PMD, as will the pfn we pull from 'entry'. + * If dax_writeback_mapping_range() was given a wbc->range_start + * in the middle of a PMD, the 'index' we use needs to be + * aligned to the start of the PMD. * This allows us to flush for PMD_SIZE and not have to worry about * partial PMD writebacks. */ pfn = dax_to_pfn(entry); - size = PAGE_SIZE << dax_entry_order(entry); + count = 1UL << dax_entry_order(entry); + index = xas->xa_index & ~(count - 1); - dax_entry_mkclean(mapping, xas->xa_index, pfn); - dax_flush(dax_dev, page_address(pfn_to_page(pfn)), size); + dax_entry_mkclean(mapping, index, pfn); + dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE); /* * After we have flushed the cache, we can clear the dirty tag. There * cannot be new dirty data in the pfn after the flush has completed as @@ -917,8 +917,7 @@ static int dax_writeback_one(struct xa_s xas_clear_mark(xas, PAGECACHE_TAG_DIRTY); dax_wake_entry(xas, entry, false); - trace_dax_writeback_one(mapping->host, xas->xa_index, - size >> PAGE_SHIFT); + trace_dax_writeback_one(mapping->host, index, count); return ret; put_unlocked: