linux-kernel - Re: [RFC PATCH 0/2] Add flag as THP allocation hint for memfd

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

Date:   Thu, 23 Feb 2023 01:31:54 +0000
From:   Ackerley Tng <ackerleytng@...gle.com>
To:     Yuan Yao <yuan.yao@...ux.intel.com>
Cc:     kvm@...r.kernel.org, linux-api@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, qemu-devel@...gnu.org, aarcange@...hat.com,
        ak@...ux.intel.com, akpm@...ux-foundation.org, arnd@...db.de,
        bfields@...ldses.org, bp@...en8.de, chao.p.peng@...ux.intel.com,
        corbet@....net, dave.hansen@...el.com, david@...hat.com,
        ddutile@...hat.com, dhildenb@...hat.com, hpa@...or.com,
        hughd@...gle.com, jlayton@...nel.org, jmattson@...gle.com,
        joro@...tes.org, jun.nakajima@...el.com,
        kirill.shutemov@...ux.intel.com, linmiaohe@...wei.com,
        luto@...nel.org, mail@...iej.szmigiero.name, mhocko@...e.com,
        michael.roth@....com, mingo@...hat.com, naoya.horiguchi@....com,
        pbonzini@...hat.com, qperret@...gle.com, rppt@...nel.org,
        seanjc@...gle.com, shuah@...nel.org, steven.price@....com,
        tabba@...gle.com, tglx@...utronix.de, vannapurve@...gle.com,
        vbabka@...e.cz, vkuznets@...hat.com, wanpengli@...cent.com,
        wei.w.wang@...el.com, x86@...nel.org, yu.c.zhang@...ux.intel.com
Subject: Re: [RFC PATCH 0/2] Add flag as THP allocation hint for
 memfd_restricted() syscall

Yuan Yao <yuan.yao@...ux.intel.com> writes:

> On Sat, Feb 18, 2023 at 12:43:00AM +0000, Ackerley Tng wrote:
>> Hello,

>> This patchset builds upon the memfd_restricted() system call that has
>> been discussed in the ‘KVM: mm: fd-based approach for supporting KVM’
>> patch series, at
>> https://lore.kernel.org/lkml/20221202061347.1070246-1-chao.p.peng@linux.intel.com/T/#m7e944d7892afdd1d62a03a287bd488c56e377b0c

>> The tree can be found at:
>> https://github.com/googleprodkernel/linux-cc/tree/restrictedmem-rmfd-hugepage

>> Following the RFC to provide mount for memfd_restricted() syscall at
>> https://lore.kernel.org/lkml/cover.1676507663.git.ackerleytng@google.com/T/#u,
>> this patchset adds the RMFD_HUGEPAGE flag to the memfd_restricted()
>> syscall, which will hint the kernel to use Transparent HugePages to
>> back restrictedmem pages.

>> This supplements the interface proposed earlier, which requires the
>> creation of a tmpfs mount to be passed to memfd_restricted(), with a
>> more direct per-file hint.

>> Dependencies:

>> + Sean’s iteration of the ‘KVM: mm: fd-based approach for supporting
>>    KVM’ patch series at
>>    https://github.com/sean-jc/linux/tree/x86/upm_base_support
>> + Proposed fix for restrictedmem_getattr() as mentioned on the mailing
>>    list at
>>     
>> https://lore.kernel.org/lkml/diqzzga0fv96.fsf@ackerleytng-cloudtop-sg.c.googlers.com/
>> + Hugh’s patch:
>>     
>> https://lore.kernel.org/lkml/c140f56a-1aa3-f7ae-b7d1-93da7d5a3572@google.com/,
>>    which provides functionality in shmem that reads the VM_HUGEPAGE
>>    flag in key functions shmem_is_huge() and shmem_get_inode()

> Will Hugh's patch be merged into 6.3 ? I didn't find it in 6.2-rc8.
> IMHO this patch won't work without Hugh's patch, or at least need
> another way, e.g. HMEM_SB(inode->i_sb)->huge.


Hugh's patch is still pending discussion and may not be merged so
soon. These patches will not work without Hugh's patch.

I would like to understand what the community thinks of the proposed
interface (RMFD_HUGEPAGE flag, passed to the memfd_restricted()
syscall). If this interface is favorably received, we can definitely
find another way for shmem to support this interface.

If I understand correctly, SHMEM_SB(inode->i_sb)->huge checks the state
of hugepage-ness for the superblock. Since the proposed interface will
only affect a single file, we will need something closer to

     bool shmem_is_huge(struct vm_area_struct *vma, struct inode *inode,
                        pgoff_t index, bool shmem_huge_force)
     {
             ...

             if (SHMEM_I(inode)->flags & VM_HUGEPAGE)
                     return true;

             ...
     }

from Hugh's patch.