linux-kernel - RE: find_get_page() VS pin_user

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: <PH0PR12MB56068CA4549ED998188D0623F09B9@PH0PR12MB5606.namprd12.prod.outlook.com>
Date:   Wed, 12 Apr 2023 12:13:38 +0000
From:   "Teterevkov, Ivan" <Ivan.Teterevkov@....com>
To:     Jan Kara <jack@...e.cz>
CC:     Alistair Popple <apopple@...dia.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "jhubbard@...dia.com" <jhubbard@...dia.com>,
        "rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
        "jglisse@...hat.com" <jglisse@...hat.com>,
        "ira.weiny@...el.com" <ira.weiny@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: find_get_page() VS pin_user_pages()

From: Jan Kara <jack@...e.cz> 
> I'm a bit confused. Above you write that:
> 
> "The memory allocation workflow begins in the userspace, which creates a new
> file backed by 2MiB hugepages with memfd_create(MFD_HUGETLB, MFD_HUGE_2MB)
> and fallocate(). Then the userspace makes an IOCTL to the kernel module
> with the file descriptor and size so that the kernel module can get the
> struct page with find_get_page()."
> 
> So the memory allocation actually does happen from fallocate(2) as far as I
> can tell. What guys are suggesting is that instead of passing the prepared
> 'fd' to ioctl(2), your application should mmap the file and pass the
> address of the mmapped area. That's how things are usually done and it also
> gives userspace more freedom over how it prepares buffers for DMA. Also then
> pin_user_pages() comes as a natural API to use in the driver.
> 

I failed to explain that the kernel module might call vfs_fallocate() to
allocate hugepages, then find_get_page() and finally dma_map_single(), all
before the userspace maps it. Sorry for the confusion.

> Now I'm not sure whether changing the ioctl(2) is still an option for you.
> If not, then you have to resort to some kind of workaround as you
> mentioned. But still pin_user_pages(FOLL_LONGTERM) is definitely the API
> you should be using for telling the kernel you are going to DMA into these
> pages and want to hold onto them for a long time.
> 

Changing the application workflow and then doing ioctl() with the address is
what I ideally want with either find_get_page() alone or vm_mmap() with
pin_user_pages() as a workaround, and the latter is preferred.

Thanks,
Ivan