On Thu, 23 Sep 2021 01:04:54 +0800 Rongwei Wang [off-list ref] wrote:

quoted

On Sep 22, 2021, at 7:37 PM, Matthew Wilcox [off-list ref] wrote:

On Wed, Sep 22, 2021 at 03:06:44PM +0800, Rongwei Wang wrote:

quoted

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 race in two possible places.

1) multiple writers truncate the same page cache concurrently;
2) collapse_file rolls back when writer truncates the page cache;

As I've said before, the bug here is that somehow there is a writable fd
to a file with THPs.  That's what we need to track down and fix.

Hi, Matthew
I am not sure get your means. We know “mm, thp: relax the VM_DENYWRITE constraint on file-backed THPs"
Introduced file-backed THPs for DSO. It is possible {very rarely} for DSO to be opened in writeable way.

...

quoted

https://lore.kernel.org/linux-mm/YUdL3lFLFHzC80Wt@casper.infradead.org/ (local)

All in all, what you mean is that we should solve this race at the source?

Matthew is being pretty clear here: we shouldn't be permitting
userspace to get a writeable fd for a thp-backed file.

Why are we permitting the DSO to be opened writeably?  If there's a
legitimate case for doing this then presumably "mm, thp: relax the
VM_DENYWRITE constraint on file-backed THPs: should be fixed or
reverted.

If there is no legitimate use case for returning a writeable fd for a
thp-backed file then we should fail such an attempt at open().  This
approach has back-compatibility issues which need to be thought about. 
Perhaps we should permit the open-writeably attempt to appear to
succeed, but to really return a read-only fd?