linux-kernel - Re: [RFC PATCH 3/4] mm/page_alloc: introduce __GFP_PTE

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]

Date:   Tue, 24 Aug 2021 16:38:03 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "rppt@...nel.org" <rppt@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Weiny, Ira" <ira.weiny@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
        "Lutomirski, Andy" <luto@...nel.org>
Subject: Re: [RFC PATCH 3/4] mm/page_alloc: introduce __GFP_PTE_MAPPED flag to
 allocate pte-mapped pages

On Tue, 2021-08-24 at 16:02 +0300, Mike Rapoport wrote:
> > We probably want to exclude GFP_ATOMIC before calling into CPA
> > unless
> > debug page alloc is on, because it may need to split and sleep for
> > the
> > allocation. There is a page table allocation with GFP_ATOMIC passed
> > actually.
> 
> Looking at the callers of alloc_low_pages() it seems that GFP_ATOMIC
> there
> is stale...
Well two actually, there is also spp_getpage(). I tried to determine if
that was also stale but wasn't confident. There were a lot of paths in.
>  
> > In my next series of this I added support for GFP_ATOMIC to this
> > code,
> > but that solution should only work for permission changing grouped
> > page
> > allocators in the protected page tables case where the direct map
> > tables are handled differently. As a general solution though
> > (that's
> > the long term intention right?), GFP_ATOMIC might deserve some
> > consideration.
> 
> ... but for the general solution GFP_ATOMIC indeed deserves some
> consideration.
>  
> > The other thing is we probably don't want to clean out the atomic
> > reserves and add them to a cache just for one page. I opted to just
> > convert one page in the GFP_ATOMIC case.
> 
>  
> Do you mean to allocate one page in GFP_ATOMIC case and bypass high
> order
> allocation?
> But the CPA split is still necessary here, isn't it?
Yes, grabs one atomic page and fragments it in the case of no pages in
the grouped page cache. The CPA split is necessary still, but it should
be ok because of the special way direct map page table allocations are
handled for pks tables. Has not been reviewed by anyone yet, and
wouldn't work as a general solution anyway.