[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180314130418.GG29631@bombadil.infradead.org>
Date: Wed, 14 Mar 2018 06:04:18 -0700
From: Matthew Wilcox <willy@...radead.org>
To: Igor Stoppa <igor.stoppa@...wei.com>
Cc: keescook@...omium.org, david@...morbit.com, rppt@...ux.vnet.ibm.com,
mhocko@...nel.org, labbott@...hat.com,
linux-security-module@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data
On Wed, Mar 14, 2018 at 02:55:10PM +0200, Igor Stoppa wrote:
> > The page_frag allocator seems like a much better place to
> > start than genalloc. It has a significantly lower overhead and is
> > much more suited to the kind of probably-identical-lifespan that the
> > pmalloc API is going to persuade its users to have.
>
> Could you please provide me a pointer?
> I did a quick search on 4.16-rc5 and found the definition of page_frag
> and sk_page_frag(). Is this what you are referring to?
It's a blink-and-you'll-miss-it allocator buried deep in mm/page_alloc.c:
void *page_frag_alloc(struct page_frag_cache *nc,
unsigned int fragsz, gfp_t gfp_mask)
void page_frag_free(void *addr)
I don't necessarily think you should use it as-is, but the principle it uses
seems like a better match to me than the rather complex genalloc. Just
allocate some pages and track the offset within those pages that is the
current allocation point. It's less than 100 lines of code!
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
