linux-kernel - Re: [PATCH v3 1/6] mm: userfaultfd: generic continue for non hugetlbfs

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <36d96316-fd9b-4755-bb35-d1a2cea7bb7e@amazon.com>
Date: Wed, 11 Jun 2025 13:09:32 +0100
From: Nikita Kalyazin <kalyazin@...zon.com>
To: Peter Xu <peterx@...hat.com>
CC: <akpm@...ux-foundation.org>, <pbonzini@...hat.com>, <shuah@...nel.org>,
	<viro@...iv.linux.org.uk>, <brauner@...nel.org>, <muchun.song@...ux.dev>,
	<hughd@...gle.com>, <kvm@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<linux-fsdevel@...r.kernel.org>, <jack@...e.cz>,
	<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <jannh@...gle.com>,
	<ryan.roberts@....com>, <david@...hat.com>, <jthoughton@...gle.com>,
	<graf@...zon.de>, <jgowans@...zon.com>, <roypat@...zon.co.uk>,
	<derekmn@...zon.com>, <nsaenz@...zon.es>, <xmarcalx@...zon.com>
Subject: Re: [PATCH v3 1/6] mm: userfaultfd: generic continue for non
 hugetlbfs



On 10/06/2025 23:22, Peter Xu wrote:
> On Fri, Apr 04, 2025 at 03:43:47PM +0000, Nikita Kalyazin wrote:
>> Remove shmem-specific code from UFFDIO_CONTINUE implementation for
>> non-huge pages by calling vm_ops->fault().  A new VMF flag,
>> FAULT_FLAG_USERFAULT_CONTINUE, is introduced to avoid recursive call to
>> handle_userfault().
> 
> It's not clear yet on why this is needed to be generalized out of the blue.
> 
> Some mentioning of guest_memfd use case might help for other reviewers, or
> some mention of the need to introduce userfaultfd support in kernel
> modules.

Hi Peter,

Sounds fair, thank you.

>>
>> Suggested-by: James Houghton <jthoughton@...gle.com>
>> Signed-off-by: Nikita Kalyazin <kalyazin@...zon.com>
>> ---
>>   include/linux/mm_types.h |  4 ++++
>>   mm/hugetlb.c             |  2 +-
>>   mm/shmem.c               |  9 ++++++---
>>   mm/userfaultfd.c         | 37 +++++++++++++++++++++++++++----------
>>   4 files changed, 38 insertions(+), 14 deletions(-)
>>
>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>> index 0234f14f2aa6..2f26ee9742bf 100644
>> --- a/include/linux/mm_types.h
>> +++ b/include/linux/mm_types.h
>> @@ -1429,6 +1429,9 @@ enum tlb_flush_reason {
>>    * @FAULT_FLAG_ORIG_PTE_VALID: whether the fault has vmf->orig_pte cached.
>>    *                        We should only access orig_pte if this flag set.
>>    * @FAULT_FLAG_VMA_LOCK: The fault is handled under VMA lock.
>> + * @FAULT_FLAG_USERFAULT_CONTINUE: The fault handler must not call userfaultfd
>> + *                                 minor handler as it is being called by the
>> + *                                 userfaultfd code itself.
> 
> We probably shouldn't leak the "CONTINUE" concept to mm core if possible,
> as it's not easy to follow when without userfault minor context.  It might
> be better to use generic terms like NO_USERFAULT.

Yes, I agree, can name it more generically.

> Said that, I wonder if we'll need to add a vm_ops anyway in the latter
> patch, whether we can also avoid reusing fault() but instead resolve the
> page faults using the vm_ops hook too.  That might be helpful because then
> we can avoid this new FAULT_FLAG_* that is totally not useful to
> non-userfault users, meanwhile we also don't need to hand-cook the vm_fault
> struct below just to suite the current fault() interfacing.

I'm not sure I fully understand that.  Calling fault() op helps us reuse 
the FS specifics when resolving the fault.  I get that the new op can 
imply the userfault flag so the flag doesn't need to be exposed to mm, 
but doing so will bring duplication of the logic within FSes between 
this new op and the fault(), unless we attempt to factor common parts 
out.  For example, for shmem_get_folio_gfp(), we would still need to 
find a way to suppress the call to handle_userfault() when 
shmem_get_folio_gfp() is called from the new op.  Is that what you're 
proposing?

> 
> Thanks,
> 
> --
> Peter Xu
>