From: igor.stoppa@huawei.com (Igor Stoppa)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 3/6] struct page: add field for vm_struct
Date: Tue, 20 Feb 2018 21:53:30 +0200 [thread overview]
Message-ID: <b59546a4-5a5b-ca48-3b51-09440b6a5493@huawei.com> (raw)
In-Reply-To: <cef01110-dc23-4442-f277-88d1d3662e00@huawei.com>
On 12/02/18 18:24, Igor Stoppa wrote:
>
>
> On 11/02/18 23:16, Matthew Wilcox wrote:
>> On Sun, Feb 11, 2018 at 05:19:17AM +0200, Igor Stoppa wrote:
>>> The struct page has a "mapping" field, which can be re-used, to store a
>>> pointer to the parent area. This will avoid more expensive searches.
>>>
>>> As example, the function find_vm_area is reimplemented, to take advantage
>>> of the newly introduced field.
>>
>> Umm. Is it more efficient? You're replacing an rb-tree search with a
>> page-table walk. You eliminate a spinlock, which is great, but is the
>> page-table walk more efficient? I suppose it'll depend on the depth of
>> the rb-tree, and (at least on x86), the page tables should already be
>> in cache.
>
> I thought the tradeoff favorable.
It turns out that it's probably not so favorable.
The patch relies on the function vmalloc_to_page ... which will return
NULL when applied to huge mappings, while the original implementation
will still work.
It was found while testing on a configuration with framebuffer.
So it seems unlikely that there is any gain to be had, from this
perspective.
The use of the field still makes sense from the perspective of adding
pmalloc support to hardened usercopy, but there is no more need for the
field to exist as separate patch.
This patch can be simplified and merged with the pmalloc patch.
--
igor
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-20 19:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
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 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-02-11 12:24 ` Mike Rapoport
2018-02-12 11:17 ` Igor Stoppa
2018-02-12 11:36 ` Mike Rapoport
2018-02-13 0:43 ` kbuild test robot
2018-02-11 3:19 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-02-11 20:22 ` Philippe Ombredanne
2018-02-11 20:27 ` Randy Dunlap
2018-02-11 21:01 ` Matthew Wilcox
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 [this message]
2018-02-20 20:54 ` Matthew Wilcox
2018-02-21 12:01 ` Igor Stoppa
2018-02-22 14:20 ` Igor Stoppa
2018-02-11 3:19 ` [PATCH 4/6] Protectable Memory Igor Stoppa
2018-02-11 12:37 ` Mike Rapoport
2018-02-12 11:26 ` Igor Stoppa
2018-02-12 11:43 ` Mike Rapoport
2018-02-12 12:53 ` Mike Rapoport
2018-02-12 13:41 ` Igor Stoppa
2018-02-12 15:31 ` Mike Rapoport
2018-02-12 15:41 ` Igor Stoppa
2018-02-11 3:19 ` [PATCH 5/6] Pmalloc: self-test Igor Stoppa
2018-02-13 2:43 ` kbuild test robot
2018-02-11 3:19 ` [PATCH 6/6] Documentation for Pmalloc Igor Stoppa
2018-02-11 21:17 ` Matthew Wilcox
2018-02-12 11:28 ` Igor Stoppa
-- 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-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-30 15:14 [RFC PATCH v12 0/6] mm: security: ro protection for dynamic data 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
2018-02-06 12:37 ` Matthew Wilcox
2018-02-09 13:45 ` 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=b59546a4-5a5b-ca48-3b51-09440b6a5493@huawei.com \
--to=igor.stoppa@huawei.com \
--cc=linux-security-module@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).