linux-kernel - Re: [PATCH 1/4] mm: Introduce vm_uffd

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: <471e95bc-ea2d-4c37-aad6-0062b4457054@redhat.com>
Date: Mon, 23 Jun 2025 19:25:11 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Nikita Kalyazin <kalyazin@...zon.com>, Hugh Dickins <hughd@...gle.com>,
 Oscar Salvador <osalvador@...e.de>, Michal Hocko <mhocko@...e.com>,
 Muchun Song <muchun.song@...ux.dev>, Andrea Arcangeli <aarcange@...hat.com>,
 Ujwal Kundur <ujwal.kundur@...il.com>, Suren Baghdasaryan
 <surenb@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Vlastimil Babka <vbabka@...e.cz>, "Liam R . Howlett"
 <Liam.Howlett@...cle.com>, James Houghton <jthoughton@...gle.com>,
 Mike Rapoport <rppt@...nel.org>, Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>, Axel Rasmussen <axelrasmussen@...gle.com>
Subject: Re: [PATCH 1/4] mm: Introduce vm_uffd_ops API

>>>
>>> How about an updated commit like this?
>>>
>>>     Currently, most of the userfaultfd features are implemented directly in the
>>>     core mm.  It will invoke VMA specific functions whenever necessary.  So far
>>>     it is fine because it almost only interacts with shmem and hugetlbfs.
>>>
>>>     This patch introduces a generic userfaultfd API for vm_operations_struct,
>>>     so that any type of file (including kernel modules that can be compiled
>>>     separately from the kernel core) can support userfaults without modifying
>>>     the core files.
>>
>> .... is it really "any file" ? I doubt it, but you likely have a better idea
>> on how it all could just work with "any file".
>>
>>>
>>>     After this API applied, if a module wants to support userfaultfd, the
>>>     module should only need to touch its own file and properly define
>>>     vm_uffd_ops, instead of changing anything in core mm.
>>>
>>>     ...
>>
>> Talking about files and modules is still confusing I'm afraid. It's really a
>> special-purpose file (really, not any ordinary files on ordinary
>> filesystems), no?
> 
> One major reason I wanted to avoid the term "in-memory" is that we already
> support most of the files on WP_ASYNC, so emphasizing on in-memory might be
> misleading, even though WP_ASYNC isn't much taken into the picture of the
> vm_uffd_ops being proposed.

Oh, yes, agreed on WP_ASYNC. But they would not be using the vma_ops 
thingy, right?

-- 
Cheers,

David / dhildenb