Messages in this thread | | | Date | Tue, 6 Mar 2018 11:34:25 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages |
| |
On Mon, Mar 05, 2018 at 11:03:55AM -0800, Dave Hansen wrote: > On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > > -#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > > - alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > > #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE > > +#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > > +({ \ > > + struct page *page; \ > > + gfp_t gfp = movableflags | GFP_HIGHUSER; \ > > + if (vma_is_encrypted(vma)) \ > > + page = __alloc_zeroed_encrypted_user_highpage(gfp, vma, vaddr); \ > > + else \ > > + page = alloc_page_vma(gfp | __GFP_ZERO, vma, vaddr); \ > > + page; \ > > +}) > > This is pretty darn ugly and also adds a big old branch into the hottest > path in the page allocator. > > It's also really odd that you strip __GFP_ZERO and then go ahead and > zero the encrypted page unconditionally. It really makes me wonder if > this is the right spot to be doing this. > > Can we not, for instance do it inside alloc_page_vma()?
Yes we can.
It would require substantial change into page allocation path for CONFIG_NUMA=n as we don't path down vma at the moment. And without vma we don't have a way to know which KeyID to use.
I will explore how it would fit together.
-- Kirill A. Shutemov
| |