linux-kernel - Re: [PATCH next 0/2] THP COW support for private executable file mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0ce50058e6254a29baee1271ae0ef31c@huawei.com>
Date: Tue, 16 Dec 2025 07:42:44 +0000
From: zhangqilong <zhangqilong3@...wei.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, Matthew Wilcox
	<willy@...radead.org>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>, "corbet@....net"
	<corbet@....net>, "ziy@...dia.com" <ziy@...dia.com>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "npache@...hat.com"
	<npache@...hat.com>, "ryan.roberts@....com" <ryan.roberts@....com>,
	"dev.jain@....com" <dev.jain@....com>, "baohua@...nel.org"
	<baohua@...nel.org>, "lance.yang@...ux.dev" <lance.yang@...ux.dev>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>,
	"surenb@...gle.com" <surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>,
	"Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@...wei.com>, Sunnanyong
	<sunnanyong@...wei.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH next 0/2] THP COW support for private executable file mmap

> On 12/16/25 03:24, zhangqilong wrote:
> >   > On 12/15/25 15:00, Matthew Wilcox wrote:
> >>> On Mon, Dec 15, 2025 at 08:34:05PM +0800, Zhang Qilong wrote:
> >>>> This patch series implementate THP COW for private executable file
> >>>> mmap. It's major designed to increase the iTLB cache hit rate for
> >>>> hot patching application, and we add a new sysfs knob to disable or
> >>>> enable it.
> >>>
> >>> You're going to have to provide data to get this patch in.  We've
> >>> deliberately not done this in the past due to memory consumption
> >> overhead.
> >>> So you need to prove that's now the wrong decision to make.
> >>>
> >>> Microbenchmarks would be a bare minimum, but what are really
> needed
> >>> are numbers from actual workloads.
> >>
> >> In addition, the sysfs toggle is rather horrible. It's rather clear
> >> that this is not a system-wide setting to be made, as you likely only
> >> want that behavior (if at all ...) for a handful of special processes I assume?
> >
> > Year, it's not a system-wide setting. We consider enabling this option
> > only when applying hot patches to special processes. If the sysfs
> > toggle is unavailable, we will evaluate the overall memory impact on
> > the system after removing it. Thanks very much for your suggestion.
> 
> I don't think we want this as any kind of default behavior. But the system
> toggle is really also not what we want. Could we use some per-VMA or per-
> file hints to affect the policy?

It's really a good idea. Maybe could setting a xx flag to VMA, but it need hold write
lock and touch VMA. let me have a think how to implement per-VMA or per-file policy
or other better hints.

I have a thought that, how about adding a new flag(in ptrace, uprobes...) and passing
to faultin_page() to mark the exec PMD COW policy?

> 
> Note that your proposal will likely interact in bad ways with uprobes, after
> removing uprobes again.

Year, good catch here, it's really need be seriously considered. 

> 
> --
> Cheers
> 
> David