LKML Archive on
help / color / mirror / Atom feed
From: Igor Stoppa <>
To: Matthew Wilcox <>
Cc: <>, <>,
	<>, <>,
	<>, <>,
	<>, <>,
Subject: Re: [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data
Date: Mon, 19 Mar 2018 20:04:35 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 14/03/18 19:33, Matthew Wilcox wrote:
> I think an implementation of
> pmalloc which used a page_frag-style allocator would be larger than
> 100 lines, but I don't think it would have to be significantly larger
> than that.

I have some doubt about what is the best way to implement it using
vmalloced memory.

1. Since I can allocate an arbitrary number of pages, I think allocating
a rounded up amount of memory, so that it's multiple of PAGE_SIZE should
be enough.

But maybe I could do better than that:
a) support pre-allocation of x pages

b) define, as pool parameter, the minimum number of pages to allocate
every time there is a refill

c) both a and b


2. the flavor of page_frag from page_alloc relies on page->_refcount,
however neither vmap_area, nor vm_struct seem to have anything like
that. (My reasoning is that I should do the accounting not on page
level, but based on the virtual area that I get when I allocate new
memory) What would be the best way to do refcounting for the area?

a) use the the page->_refcount from the first page that belongs to the area

b) add the _refcount to either vm_struct or vmap_area (I am not really
sure of why these two structures exist as separate entities, rather than
a single one - cache optimization?)


3. I will have to add a list of chunks (in genalloc lingo, or areas, if
we refer to the new implementation), because I will still need to
iterate over all the memory that belongs to a pool, for either write
protecting it or for destroying the pool. I have two options:

a) handle the chunks within the pmalloc pool

b) create an intermediate type of pool (vfrag_pool?) and then include it
in the pmalloc pool structure.

I'd lean toward option a, but I thought I might as well ask for advice
before I implement the less desirable option (whatever it might be).

thanks, igor

      parent reply	other threads:[~2018-03-19 18:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 21:45 [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data Igor Stoppa
2018-03-13 21:45 ` [PATCH 1/8] genalloc: track beginning of allocations Igor Stoppa
2018-03-13 21:45 ` [PATCH 2/8] Add label to genalloc.rst for cross reference Igor Stoppa
2018-03-13 21:45 ` [PATCH 3/8] genalloc: selftest Igor Stoppa
2018-03-13 21:45 ` [PATCH 4/8] struct page: add field for vm_struct Igor Stoppa
2018-03-13 22:00   ` Matthew Wilcox
2018-03-14 17:43     ` J Freyensee
2018-03-15  9:38       ` Igor Stoppa
2018-03-15 18:51         ` J Freyensee
2018-03-13 21:45 ` [PATCH 5/8] Protectable Memory Igor Stoppa
2018-03-14 12:15   ` Matthew Wilcox
2018-03-14 13:02     ` Igor Stoppa
2018-03-14 17:40       ` J Freyensee
2018-03-13 21:45 ` [PATCH 6/8] Pmalloc selftest Igor Stoppa
2018-03-14 12:25   ` Matthew Wilcox
2018-03-25  1:32     ` Igor Stoppa
2018-03-13 21:45 ` [PATCH 7/8] lkdtm: crash on overwriting protected pmalloc var Igor Stoppa
2018-03-13 21:45 ` [PATCH 8/8] Documentation for Pmalloc Igor Stoppa
2018-03-14 11:21 ` [RFC PATCH v19 0/8] mm: security: ro protection for dynamic data Igor Stoppa
2018-03-14 11:56   ` Matthew Wilcox
2018-03-14 12:55     ` Igor Stoppa
2018-03-14 13:04       ` Matthew Wilcox
2018-03-14 16:11         ` Igor Stoppa
2018-03-14 17:33           ` Matthew Wilcox
2018-03-15 13:43             ` Igor Stoppa
2018-03-19 18:04             ` Igor Stoppa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).