From: Rik van Riel <riel@redhat.com>
To: Michel Lespinasse <walken@google.com>
Cc: Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 4/6] mm: vm_unmapped_area() lookup function
Date: Fri, 02 Nov 2012 12:52:18 -0400 [thread overview]
Message-ID: <5093FA42.50806@redhat.com> (raw)
In-Reply-To: <1351679605-4816-5-git-send-email-walken@google.com>
On 10/31/2012 06:33 AM, Michel Lespinasse wrote:
> +/*
> + * Search for an unmapped address range.
> + *
> + * We are looking for a range that:
> + * - does not intersect with any VMA;
> + * - is contained within the [low_limit, high_limit[ interval;
^
bracket is the wrong way around :)
> + * - is at least the desired size.
> + * - satisfies (begin_addr & align_mask) == (align_offset & align_mask)
> + */
> +static inline unsigned long
> +vm_unmapped_area(struct vm_unmapped_area_info *info)
> +{
> + if (!(info->flags & VM_UNMAPPED_AREA_TOPDOWN))
> + return unmapped_area(info);
> + else
> + return unmapped_area_topdown(info);
> +}
I like how you pass all the info in the struct. That solves
some of the problems I was trying to deal with when I implemented
something similar.
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1494,6 +1494,206 @@ unacct_error:
> return error;
> }
>
> +unsigned long unmapped_area(struct vm_unmapped_area_info *info)
> +{
> + /*
> + * We implement the search by looking for an rbtree node that
> + * immediately follows a suitable gap. That is,
> + * - gap_start = vma->vm_prev->vm_end <= info->high_limit - length;
> + * - gap_end = vma->vm_start >= info->low_limit + length;
> + * - gap_end - gap_start >= length
> + */
> +
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
> +
> + /* Adjust search length to account for worst case alignment overhead */
> + length = info->length + info->align_mask;
> + if (length < info->length)
> + return -ENOMEM;
If we unmap a VMA that is size N and correctly aligned, then
we may leave a gap of size N.
A subsequent call to mmap should be able to find that gap,
and use it.
It may make sense to not add the align_mask the first time
around, and see if the gap that we find already has the
correct alignment.
If it does not, we can always add the align_mask, and do
a second search for a hole of N + align_mask:
if (hole not aligned) {
length += info->align_mask;
goto again;
}
> @@ -1603,53 +1777,12 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
> return addr;
> }
>
...
> + info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> + info.length = len;
> + info.low_limit = 0;
> + info.high_limit = mm->mmap_base;
> + info.align_mask = 0;
> + addr = vm_unmapped_area(&info);
I believe it would be better to set low_limit to PAGE_SIZE.
Otherwise we can return 0, which is indistinguishable from a null
pointer. Keeping address 0 unmapped provides the security benefit
that code that can be made to address null pointers causes a crash,
instead of a potential privilege escalation.
The rest of the patch looks good.
--
All rights reversed
--
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>
next prev parent reply other threads:[~2012-11-02 16:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 10:33 [RFC PATCH 0/6] mm: use augmented rbtrees for finding unmapped areas Michel Lespinasse
2012-10-31 10:33 ` [RFC PATCH 1/6] mm: augment vma rbtree with rb_subtree_gap Michel Lespinasse
2012-11-01 21:43 ` Rik van Riel
2012-10-31 10:33 ` [RFC PATCH 2/6] mm: check rb_subtree_gap correctness Michel Lespinasse
2012-11-01 21:49 ` Rik van Riel
2012-10-31 10:33 ` [RFC PATCH 3/6] mm: rearrange vm_area_struct for fewer cache misses Michel Lespinasse
2012-10-31 10:33 ` [RFC PATCH 4/6] mm: vm_unmapped_area() lookup function Michel Lespinasse
2012-11-02 16:52 ` Rik van Riel [this message]
2012-11-02 22:41 ` Michel Lespinasse
2012-11-03 0:40 ` Rik van Riel
2012-10-31 10:33 ` [RFC PATCH 5/6] mm: use vm_unmapped_area() on x86_64 architecture Michel Lespinasse
2012-11-02 20:39 ` Rik van Riel
2012-10-31 10:33 ` [RFC PATCH 6/6] mm: fix cache coloring on x86_64 Michel Lespinasse
2012-10-31 11:03 ` [RFC PATCH 0/6] mm: use augmented rbtrees for finding unmapped areas Michel Lespinasse
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=5093FA42.50806@redhat.com \
--to=riel@redhat.com \
--cc=aarcange@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=peterz@infradead.org \
--cc=walken@google.com \
/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).