linux-kernel - Re: [PATCH v3 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: <9089d994-262f-4941-8bed-f3c6ee05a769@redhat.com>
Date: Tue, 7 Oct 2025 18:14:01 +0200
From: David Hildenbrand <david@...hat.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Peter Xu
 <peterx@...hat.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Axel Rasmussen <axelrasmussen@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
 James Houghton <jthoughton@...gle.com>, Nikita Kalyazin
 <kalyazin@...zon.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Ujwal Kundur <ujwal.kundur@...il.com>, Mike Rapoport <rppt@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Andrea Arcangeli <aarcange@...hat.com>, Michal Hocko <mhocko@...e.com>,
 Muchun Song <muchun.song@...ux.dev>, Oscar Salvador <osalvador@...e.de>,
 Hugh Dickins <hughd@...gle.com>, Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH v3 1/4] mm: Introduce vm_uffd_ops API

>> If so, I'd prefer that rather than introducing feature-backend flags,
>> because I want to avoid introducing another different feature set to uffd.
>>
> 
> I was talking about uffd_features.  I thought it was being renamed to
> flags, not modes_supported.  It was pretty late when I responded.
> 
> FWIU, David was saying we don't need both of modes and ioctl listed in
> the uffd_ops?

Right, I would have abstracted the features to clean it up and avoid 
using VM_ flags in this interface.

> 
> I was thinking that we could just put the features directly as function
> pointers in the uffd_ops and check if they are NULL or not for
> 'support'.
> 
> ie:
> 
> struct vm_uffd_ops hugetlb_uffd_ops = {
>          .missing = hugetlb_handle_userfault,
>          .write_protect = mwriteprotect_range,
>          .minor = hugetlb_handle_userfault_minor,
> 
>          .mfill_atomic = hugetlb_mfill_atomic_pte,
>          .mfill_atomic_continue = ...
>          .mfill_zeropage = ...
>          .mfill_poison = ...
>          .mfill_copy = NULL, /* For example */
> };
> 
> Then mfill_atomic_copy() becomes:
> {
>          /*
>           * Maybe some setup, used for all mfill operations from
>           * mfill_atomic()
>           */
> 
>           ...
> 
>          dst_vma = uffd_mfill_lock()
>          uffd_ops = vma_get_uffd_ops(vma);
>          if (!uffd_ops)
>                  return false;
> 
>          if (!uffd_ops->mfill_copy) /* unlikely? */
>                  return false;
> 
>          return uffd_ops->mfill_copy(dst_vma,..);
> }
> 
> This way is_vm_hugetlb_page() never really needs to be used because the
> function pointer already makes that distinction.
> 
> Right now, we have checks for hugetlb through other functions that "pass
> off to appropriate routine", and we end up translating the
> ioctl_supports into the function call eventually, anyways.

Right, it would be great to get rid of that. I recall I asked for such a 
cleanup in RFC (or was it v1).

-- 
Cheers

David / dhildenb