linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] fix two bugs for file THP
@ 2021-10-25  9:21 Rongwei Wang
  2021-10-25  9:21 ` [PATCH 1/2] mm, thp: lock filemap when truncating page cache Rongwei Wang
  2021-10-25  9:21 ` [PATCH 2/2] mm, thp: fix incorrect unmap behavior for private pages Rongwei Wang
  0 siblings, 2 replies; 3+ messages in thread
From: Rongwei Wang @ 2021-10-25  9:21 UTC (permalink / raw)
  To: akpm, willy, song, william.kucharski, hughd, shy828301
  Cc: linux-mm, linux-kernel, stable

Patch 1/2 had been sent about weeks ago, the original
link here:
https://patchwork.kernel.org/project/linux-mm/patch/20211011022241.97072-2-rongwei.wang@linux.alibaba.com/
It seems to be ignored, and send out again here.

Patch 2/2 is sent out first time. And Patch 1/2 and
2/2 both to fix different bugs for commit
eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed
THPs").

In addition, I find the stable version (I had check 5.14) has contained
above commit (eb6ecbed0aa2), so I will add "cc stable mail list"
when sending Patches.

Thanks!

Rongwei Wang (2):
  mm, thp: lock filemap when truncating page cache
  mm, thp: fix incorrect unmap behavior for private pages

 fs/open.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

-- 
2.27.0



^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH 1/2] mm, thp: lock filemap when truncating page cache
  2021-10-25  9:21 [PATCH 0/2] fix two bugs for file THP Rongwei Wang
@ 2021-10-25  9:21 ` Rongwei Wang
  2021-10-25  9:21 ` [PATCH 2/2] mm, thp: fix incorrect unmap behavior for private pages Rongwei Wang
  1 sibling, 0 replies; 3+ messages in thread
From: Rongwei Wang @ 2021-10-25  9:21 UTC (permalink / raw)
  To: akpm, willy, song, william.kucharski, hughd, shy828301
  Cc: linux-mm, linux-kernel, stable

Transparent huge page has supported read-only non-shmem files. The file-
backed THP is collapsed by khugepaged and truncated when written (for
shared libraries).

However, there is a race when multiple writers truncate the same page
cache concurrently.

In that case, subpage(s) of file THP can be revealed by find_get_entry
in truncate_inode_pages_range, which will trigger PageTail BUG_ON in
truncate_inode_page, as follows.

page:000000009e420ff2 refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff pfn:0x50c3ff
head:0000000075ff816d order:9 compound_mapcount:0 compound_pincount:0
flags: 0x37fffe0000010815(locked|uptodate|lru|arch_1|head)
raw: 37fffe0000000000 fffffe0013108001 dead000000000122 dead000000000400
raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
head: 37fffe0000010815 fffffe001066bd48 ffff000404183c20 0000000000000000
head: 0000000000000600 0000000000000000 00000001ffffffff ffff000c0345a000
page dumped because: VM_BUG_ON_PAGE(PageTail(page))
------------[ cut here ]------------
kernel BUG at mm/truncate.c:213!
Internal error: Oops - BUG: 0 [#1] SMP
Modules linked in: xfs(E) libcrc32c(E) rfkill(E) ...
CPU: 14 PID: 11394 Comm: check_madvise_d Kdump: ...
Hardware name: ECS, BIOS 0.0.0 02/06/2015
pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
pc : truncate_inode_page+0x64/0x70
lr : truncate_inode_page+0x64/0x70
sp : ffff80001b60b900
x29: ffff80001b60b900 x28: 00000000000007ff
x27: ffff80001b60b9a0 x26: 0000000000000000
x25: 000000000000000f x24: ffff80001b60b9a0
x23: ffff80001b60ba18 x22: ffff0001e0999ea8
x21: ffff0000c21db300 x20: ffffffffffffffff
x19: fffffe001310ffc0 x18: 0000000000000020
x17: 0000000000000000 x16: 0000000000000000
x15: ffff0000c21db960 x14: 3030306666666620
x13: 6666666666666666 x12: 3130303030303030
x11: ffff8000117b69b8 x10: 00000000ffff8000
x9 : ffff80001012690c x8 : 0000000000000000
x7 : ffff8000114f69b8 x6 : 0000000000017ffd
x5 : ffff0007fffbcbc8 x4 : ffff80001b60b5c0
x3 : 0000000000000001 x2 : 0000000000000000
x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 truncate_inode_page+0x64/0x70
 truncate_inode_pages_range+0x550/0x7e4
 truncate_pagecache+0x58/0x80
 do_dentry_open+0x1e4/0x3c0
 vfs_open+0x38/0x44
 do_open+0x1f0/0x310
 path_openat+0x114/0x1dc
 do_filp_open+0x84/0x134
 do_sys_openat2+0xbc/0x164
 __arm64_sys_openat+0x74/0xc0
 el0_svc_common.constprop.0+0x88/0x220
 do_el0_svc+0x30/0xa0
 el0_svc+0x20/0x30
 el0_sync_handler+0x1a4/0x1b0
 el0_sync+0x180/0x1c0
Code: aa0103e0 900061e1 910ec021 9400d300 (d4210000)
---[ end trace f70cdb42cb7c2d42 ]---
Kernel panic - not syncing: Oops - BUG: Fatal exception

This patch mainly to lock filemap when one enter truncate_pagecache(),
avoiding truncating the same page cache concurrently.

Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
Cc: <stable@vger.kernel.org>
Suggested-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Tested-by: Song Liu <song@kernel.org>
Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
---
 fs/open.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index a7f6cab81267..e73bf88e5060 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -856,8 +856,11 @@ static int do_dentry_open(struct file *f,
 		 * of THPs into the page cache will fail.
 		 */
 		smp_mb();
-		if (filemap_nr_thps(inode->i_mapping))
+		if (filemap_nr_thps(inode->i_mapping)) {
+			filemap_invalidate_lock(inode->i_mapping);
 			truncate_pagecache(inode, 0);
+			filemap_invalidate_unlock(inode->i_mapping);
+		}
 	}
 
 	return 0;
-- 
2.27.0



^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [PATCH 2/2] mm, thp: fix incorrect unmap behavior for private pages
  2021-10-25  9:21 [PATCH 0/2] fix two bugs for file THP Rongwei Wang
  2021-10-25  9:21 ` [PATCH 1/2] mm, thp: lock filemap when truncating page cache Rongwei Wang
@ 2021-10-25  9:21 ` Rongwei Wang
  1 sibling, 0 replies; 3+ messages in thread
From: Rongwei Wang @ 2021-10-25  9:21 UTC (permalink / raw)
  To: akpm, willy, song, william.kucharski, hughd, shy828301
  Cc: linux-mm, linux-kernel, stable

When truncating pagecache on file THP, the private pages
of a process should not be unmapped mapping. This
incorrect behavior on a dynamic shared libraries which
will cause related processes to happen core dump.

A simple test for a DSO (Prerequisite is the DSO mapped
in file THP):

int main(int argc, char *argv[])
{
	int fd;

	fd = open(argv[1], O_WRONLY);
	if (fd < 0) {
		perror("open");
	}

	close(fd);
	return 0;
}

The test only to open a target DSO, and do nothing. But
this operation will lead one or more process to happen
core dump. This patch mainly to fix this bug.

Fixes: eb6ecbed0aa2 ("mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs")
Cc: <stable@vger.kernel.org>
Tested-by: Xu Yu <xuyu@linux.alibaba.com>
Signed-off-by: Rongwei Wang <rongwei.wang@linux.alibaba.com>
---
 fs/open.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index e73bf88e5060..f732fb94600c 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -857,8 +857,17 @@ static int do_dentry_open(struct file *f,
 		 */
 		smp_mb();
 		if (filemap_nr_thps(inode->i_mapping)) {
+			struct address_space *mapping = inode->i_mapping;
+
 			filemap_invalidate_lock(inode->i_mapping);
-			truncate_pagecache(inode, 0);
+			/*
+			 * unmap_mapping_range just need to be called once
+			 * here, because the private pages is not need to be
+			 * unmapped mapping (e.g. data segment of dynamic
+			 * shared libraries here).
+			 */
+			unmap_mapping_range(mapping, 0, 0, 0);
+			truncate_inode_pages(mapping, 0);
 			filemap_invalidate_unlock(inode->i_mapping);
 		}
 	}
-- 
2.27.0



^ permalink raw reply related	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-25  9:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-25  9:21 [PATCH 0/2] fix two bugs for file THP Rongwei Wang
2021-10-25  9:21 ` [PATCH 1/2] mm, thp: lock filemap when truncating page cache Rongwei Wang
2021-10-25  9:21 ` [PATCH 2/2] mm, thp: fix incorrect unmap behavior for private pages Rongwei Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).