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: Wed, 14 Mar 2018 18:11:22 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 14/03/18 15:04, Matthew Wilcox wrote:

> I don't necessarily think you should use it as-is,

I think I simply cannot use it as-is, because it seems to use linear
memory, while I need virtual. This reason alone would require a rewrite
of several parts.

> but the principle it uses
> seems like a better match to me than the rather complex genalloc.

It uses meta data in a different way than genalloc.
There is probably a tipping point where one implementation becomes more
space-efficient than the other.

Probably page_frag does well with relatively large allocations, while
genalloc seems to be better for small (few allocation units) allocations.

Also, in case of high variance in the size of the allocations, genalloc
requires the allocation unit to be small enough to fit the smallest
request (otherwise one must accept some slack), while page_frag doesn't
care if the allocation is small or large.

page_frag otoh, seems to not support the reuse of space that was freed,
since there is only

But could you please explain to what you are referring to, when you say
that page_frag has "significantly lower overhead" ?

Is it because it doesn't try to reclaim space that was freed, until the
whole page is empty?

I see different trade-offs, but I am probably either missing or
underestimating the main reason why you think this is better.

And probably I am missing the capability of judging what is acceptable
in certain cases.

Ex: if the pfree is called only on error paths, is it ok to not claim
back the memory released, if it's less than one page?

To be clear: I do not want to hold to genalloc just because I have
already implemented it. I can at least sketch a version with page_frag,
but I would like to understand why its trade-offs are better :-)

> 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!

Strictly speaking it is true, but it all relies on other functions,
which must be rewritten, because they use linear address, while this
must work with virtual (vmalloc) addresses.

Also, I see that the code relies a lot on order of allocation.
I think we had similar discussion wrt compound pages.

It seems to me wasteful, if I have a request of, say, 5 pages, and I end
up allocating 8.

I do not recall anyone giving a justification like:
"yeah, it uses extra pages, but it's preferable, for reasons X, Y and Z,
so it's a good trade-off"

Could it be that it's normal RAM is considered less precious than the
special memory genalloc is written for, so normal RAM is not really
proactively reused, while special memory is treated as a more valuable
resource that should not be wasted?


  reply	other threads:[~2018-03-14 16:11 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 [this message]
2018-03-14 17:33           ` Matthew Wilcox
2018-03-15 13:43             ` Igor Stoppa
2018-03-19 18:04             ` Igor Stoppa

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).