linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@huawei.com>
To: Christopher Lameter <cl@linux.com>
Cc: jglisse@redhat.com, keescook@chromium.org, mhocko@kernel.org,
	labbott@redhat.com, hch@infradead.org, willy@infradead.org,
	linux-security-module@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 3/6] struct page: add field for vm_struct
Date: Fri, 9 Feb 2018 13:34:05 +0200	[thread overview]
Message-ID: <47f64329-32e2-44ba-c878-ee3cccdebfea@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1802050931190.10647@nuc-kabylake>



On 05/02/18 17:33, Christopher Lameter wrote:
> On Sat, 3 Feb 2018, Igor Stoppa wrote:
> 
>> - the property of the compound page will affect the property of all the
>> pages in the compound, so when one is write protected, it can generate a
>> lot of wasted memory, if there is too much slack (because of the order)
>> With vmalloc, I can allocate any number of pages, minimizing the waste.
> 
> I thought the intend here is to create a pool where the whole pool becomes
> RO?

Yes, but why would I force the number of pages in the pool to be a power
of 2, when it can be any number?

If a need, say, 17 pages, I would have to allocate 32.
But it can be worse than that.
Since the size of the overall allocated memory is not known upfront, I
wold have a problem to decide how many pages to allocate, every time
there is need to grow the pool.

Or push the problem to the user of the API, who might be equally unaware.

Notice that there is already a function (prealloc) available to the user
of the API, if the size is known upfront.

So I do not really see how using compound pages would make memory
utilization better or even not worse.

--
igor

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2018-02-09 11:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 15:14 [RFC PATCH v12 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-01-30 15:14 ` [PATCH 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-01-30 15:14 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-01-30 15:14 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-01  0:00   ` Christopher Lameter
2018-02-01 12:42     ` Igor Stoppa
2018-02-01 21:11       ` Kees Cook
2018-02-02 16:01         ` Igor Stoppa
2018-02-02 18:43       ` Christopher Lameter
2018-02-03 16:13         ` Igor Stoppa
2018-02-05 15:33           ` Christopher Lameter
2018-02-09 11:34             ` Igor Stoppa [this message]
2018-02-06 12:37   ` Matthew Wilcox
2018-02-09 13:45     ` Igor Stoppa
2018-01-30 15:14 ` [PATCH 4/6] Protectable Memory Igor Stoppa
2018-02-02  5:41   ` kbuild test robot
2018-02-02  5:53   ` kbuild test robot
2018-01-30 15:14 ` [PATCH 5/6] Documentation for Pmalloc Igor Stoppa
2018-01-30 17:08   ` Jonathan Corbet
2018-02-02 15:56     ` Igor Stoppa
2018-02-10  3:37       ` Matthew Wilcox
2018-02-12 15:28         ` Jonathan Corbet
2018-01-30 15:14 ` [PATCH 6/6] Pmalloc: self-test Igor Stoppa
2018-02-02  6:14   ` kbuild test robot
  -- strict thread matches above, loose matches on Subject: below --
2018-02-12 16:52 [RFC PATCH v16 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-12 16:52 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-11  3:19 [RFC PATCH v15 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-11  3:19 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-11 21:16   ` Matthew Wilcox
2018-02-12 16:24     ` Igor Stoppa
2018-02-20 19:53       ` Igor Stoppa
2018-02-20 20:54         ` Matthew Wilcox
2018-02-21 12:01           ` Igor Stoppa
2018-02-22 14:20             ` Igor Stoppa
2018-02-04 16:47 [RFC PATCH v14 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-04 16:47 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-02-03 19:42 [RFC PATCH v13 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-02-03 19:42 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-01-24 17:56 [RFC PATCH v11 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-01-24 17:56 ` [PATCH 3/6] struct page: add field for vm_struct 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=47f64329-32e2-44ba-c878-ee3cccdebfea@huawei.com \
    --to=igor.stoppa@huawei.com \
    --cc=cl@linux.com \
    --cc=hch@infradead.org \
    --cc=jglisse@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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