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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.