Home Home > GIT Browse > stable
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJiri Slaby <jslaby@suse.cz>2019-08-16 22:01:45 +0200
committerJiri Slaby <jslaby@suse.cz>2019-08-16 22:25:11 +0200
commit12fea4a49ff81cc81d2153a55ae7537b3563a238 (patch)
treea087e400d92c944fdc655057988a28556fe7cab6
parent1c24455dce03397f028258b91918101c4bf046ef (diff)
dax: dax_layout_busy_page() should not unmap cow pages
-rw-r--r--patches.kernel.org/5.2.9-131-dax-dax_layout_busy_page-should-not-unmap-cow-p.patch65
-rw-r--r--series.conf1
2 files changed, 66 insertions, 0 deletions
diff --git a/patches.kernel.org/5.2.9-131-dax-dax_layout_busy_page-should-not-unmap-cow-p.patch b/patches.kernel.org/5.2.9-131-dax-dax_layout_busy_page-should-not-unmap-cow-p.patch
new file mode 100644
index 0000000000..0d6fa4ece4
--- /dev/null
+++ b/patches.kernel.org/5.2.9-131-dax-dax_layout_busy_page-should-not-unmap-cow-p.patch
@@ -0,0 +1,65 @@
+From: Vivek Goyal <vgoyal@redhat.com>
+Date: Fri, 2 Aug 2019 15:29:56 -0400
+Subject: [PATCH] dax: dax_layout_busy_page() should not unmap cow pages
+References: bnc#1012628
+Patch-mainline: 5.2.9
+Git-commit: d75996dd022b6d83bd14af59b2775b1aa639e4b9
+
+commit d75996dd022b6d83bd14af59b2775b1aa639e4b9 upstream.
+
+Vivek:
+
+ "As of now dax_layout_busy_page() calls unmap_mapping_range() with last
+ argument as 1, which says even unmap cow pages. I am wondering who needs
+ to get rid of cow pages as well.
+
+ I noticed one interesting side affect of this. I mount xfs with -o dax and
+ mmaped a file with MAP_PRIVATE and wrote some data to a page which created
+ cow page. Then I called fallocate() on that file to zero a page of file.
+ fallocate() called dax_layout_busy_page() which unmapped cow pages as well
+ and then I tried to read back the data I wrote and what I get is old
+ data from persistent memory. I lost the data I had written. This
+ read basically resulted in new fault and read back the data from
+ persistent memory.
+
+ This sounds wrong. Are there any users which need to unmap cow pages
+ as well? If not, I am proposing changing it to not unmap cow pages.
+
+ I noticed this while while writing virtio_fs code where when I tried
+ to reclaim a memory range and that corrupted the executable and I
+ was running from virtio-fs and program got segment violation."
+
+Dan:
+
+ "In fact the unmap_mapping_range() in this path is only to synchronize
+ against get_user_pages_fast() and force it to call back into the
+ filesystem to re-establish the mapping. COW pages should be left
+ untouched by dax_layout_busy_page()."
+
+Cc: <stable@vger.kernel.org>
+Fixes: 5fac7408d828 ("mm, fs, dax: handle layout changes to pinned dax mappings")
+Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
+Link: https://lore.kernel.org/r/20190802192956.GA3032@redhat.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+---
+ fs/dax.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/dax.c b/fs/dax.c
+index 7d0e99982d48..4f42b852375b 100644
+--- a/fs/dax.c
++++ b/fs/dax.c
+@@ -601,7 +601,7 @@ struct page *dax_layout_busy_page(struct address_space *mapping)
+ * guaranteed to either see new references or prevent new
+ * references from being established.
+ */
+- unmap_mapping_range(mapping, 0, 0, 1);
++ unmap_mapping_range(mapping, 0, 0, 0);
+
+ xas_lock_irq(&xas);
+ xas_for_each(&xas, entry, ULONG_MAX) {
+--
+2.22.0
+
diff --git a/series.conf b/series.conf
index 4de0ff82b4..ac4545eb29 100644
--- a/series.conf
+++ b/series.conf
@@ -1151,6 +1151,7 @@
patches.kernel.org/5.2.9-128-ALSA-hda-Don-t-override-global-PCM-hw-info-flag.patch
patches.kernel.org/5.2.9-129-ALSA-hda-Workaround-for-crackled-sound-on-AMD-c.patch
patches.kernel.org/5.2.9-130-mac80211-don-t-WARN-on-short-WMM-parameters-fro.patch
+ patches.kernel.org/5.2.9-131-dax-dax_layout_busy_page-should-not-unmap-cow-p.patch
########################################################
# Build fixes that apply to the vanilla kernel too.