[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a186f0f-c192-4e89-a11f-705c78d52233@kernel.org>
Date: Wed, 11 Feb 2026 17:44:34 +0100
From: "David Hildenbrand (Arm)" <david@...nel.org>
To: Ackerley Tng <ackerleytng@...gle.com>,
Deepanshu Kartikey <kartikey406@...il.com>
Cc: akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
baolin.wang@...ux.alibaba.com, Liam.Howlett@...cle.com, npache@...hat.com,
ryan.roberts@....com, dev.jain@....com, baohua@...nel.org,
seanjc@...gle.com, pbonzini@...hat.com, michael.roth@....com,
vannapurve@...gle.com, ziy@...dia.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
syzbot+33a04338019ac7e43a44@...kaller.appspotmail.com
Subject: Re: [PATCH] mm: thp: Deny THP for guest_memfd and secretmem in
file_thp_enabled()
On 2/11/26 17:35, David Hildenbrand (Arm) wrote:
> On 2/11/26 17:16, Ackerley Tng wrote:
>> "David Hildenbrand (Arm)" <david@...nel.org> writes:
>>
>>>
>>>
>>> Do you have a reproducer? If so, which behavior does it trigger?
>>>
>>> I would assume that we would suddenly have secretmem pages (THP) that
>>> have a directmap. Or some page copy would crash the kernel.
>>>
>>
>> Is there a good way to verify from userspace that the directmap hasn't
>> been restored? Should I use CONFIG_PTDUMP_DEBUGFS?
>
> Anything that uses GUP must fail on that secretmem memory. Like doing an
> O_DIRECT read/write or using vmsplice.
>
Ah, but that might still fail, because we can identify the page as such.
Hm ... we'd need some introspection interface indeed.
--
Cheers,
David
Powered by blists - more mailing lists