Skip to contentSkip to conversation

FAILED: patch "[PATCH] dax: Check page->mapping isn't NULL" failed to apply to 4.19-stable tree

PATCH [email protected] 2 participants 3 messages Dec 11, 2018 – Dec 14, 2018

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

Quoted 1 line

From c93db7bb6ef3251e0ea48ade311d3e9942748e1c Mon Sep 17 00:00:00 2001

From: Matthew Wilcox <[email protected]>
Date: Tue, 27 Nov 2018 13:16:33 -0800
Subject: [PATCH] dax: Check page->mapping isn't NULL

If we race with inode destroy, it's possible for page->mapping to be NULL before we even enter this routine, as well as after having slept waiting for the dax entry to become unlocked.

Fixes c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
fs/dax.c +1 -1
index 9bcce89ea18e..e69fc231833b 100644
@@ -365,7 +365,7 @@ bool dax_lock_mapping_entry(struct page *page)
 		struct address_space *mapping = READ_ONCE(page->mapping);
 
 		locked = false;
-		if (!dax_mapping(mapping))
+		if (!mapping || !dax_mapping(mapping))
 			break;
 
 		/*
reviewer Reviewed-by Johannes Thumshirn Reviewed-by Jan Kara
#1 lore raw
Quoted 7 lines · On Tue, Dec 11, 2018 at 03:00:15PM +0100, [email protected] wrote:

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

From ebcfdf7933e1c72dbe581e64064bc6b8bb5d8694 Mon Sep 17 00:00:00 2001

From: Matthew Wilcox <[email protected]>
Date: Tue, 11 Dec 2018 09:41:48 -0500
Subject: [PATCH 1/2] dax: Check page->mapping isn't NULL

commit c93db7bb6ef3251e0ea48ade311d3e9942748e1c upstream.

If we race with inode destroy, it's possible for page->mapping to be NULL before we even enter this routine, as well as after having slept waiting for the dax entry to become unlocked.

Fixes c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/dax.c +1 -1
index b0cd1364c68f..3a2682a6c832 100644
@@ -423,7 +423,7 @@ bool dax_lock_mapping_entry(struct page *page)
 	for (;;) {
 		mapping = READ_ONCE(page->mapping);
 
-		if (!dax_mapping(mapping))
+		if (!mapping || !dax_mapping(mapping))
 			break;
 
 		/*
Signature · 1 line
2.19.1
author maintainer
#2 lore raw
Quoted 25 lines · Matthew Wilcox
Quoted 7 lines · On Tue, Dec 11, 2018 at 03:00:15PM +0100, [email protected] wrote:

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

From ebcfdf7933e1c72dbe581e64064bc6b8bb5d8694 Mon Sep 17 00:00:00 2001

From: Matthew Wilcox <[email protected]>
Date: Tue, 11 Dec 2018 09:41:48 -0500
Subject: [PATCH 1/2] dax: Check page->mapping isn't NULL

commit c93db7bb6ef3251e0ea48ade311d3e9942748e1c upstream.

If we race with inode destroy, it's possible for page->mapping to be NULL before we even enter this routine, as well as after having slept waiting for the dax entry to become unlocked.

Fixes c2a7d2a11552 ("filesystem-dax: Introduce dax_lock_mapping_entry()")
Quoted 3 lines
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Now applied, thanks.

greg k-h