From: dave@linux.vnet.ibm.com (Dave Hansen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/12] mm: alloc_contig_freed_pages() added
Date: Thu, 31 Mar 2011 08:58:03 -0700 [thread overview]
Message-ID: <1301587083.31087.1032.camel@nimitz> (raw)
In-Reply-To: <1301577368-16095-5-git-send-email-m.szyprowski@samsung.com>
On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
>
> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
> + gfp_t flag)
> +{
> + unsigned long pfn = start, count;
> + struct page *page;
> + struct zone *zone;
> + int order;
> +
> + VM_BUG_ON(!pfn_valid(start));
This seems kinda mean. Could we return an error? I understand that
this is largely going to be an early-boot thing, but surely trying to
punt on crappy input beats a full-on BUG().
if (!pfn_valid(start))
return -1;
> + zone = page_zone(pfn_to_page(start));
> +
> + spin_lock_irq(&zone->lock);
> +
> + page = pfn_to_page(pfn);
> + for (;;) {
> + VM_BUG_ON(page_count(page) || !PageBuddy(page));
> + list_del(&page->lru);
> + order = page_order(page);
> + zone->free_area[order].nr_free--;
> + rmv_page_order(page);
> + __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
> + pfn += 1 << order;
> + if (pfn >= end)
> + break;
If start->end happens to span the end of a zone, I believe this will
jump out of the zone. It will still be pfn_valid(), but potentially not
in the same zone.
> + VM_BUG_ON(!pfn_valid(pfn));
> + page += 1 << order;
> + }
That will break on SPARSEMEM. You potentially need to revalidate the
pfn->page mapping on every MAX_ORDER pfn change. It's easiest to just
do pfn_to_page() on each loop.
> +
> + spin_unlock_irq(&zone->lock);
>
> +void free_contig_pages(struct page *page, int nr_pages)
> +{
> + for (; nr_pages; --nr_pages, ++page)
> + __free_page(page);
> +}
Can't help but notice that this resembles a bit of a patch I posted last
week:
http://www.spinics.net/lists/linux-mm/msg16364.html
We'll have to make sure we only have one copy of this in the end.
-- Dave
next prev parent reply other threads:[~2011-03-31 15:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-31 13:15 [PATCHv9 0/12] Contiguous Memory Allocator Marek Szyprowski
2011-03-31 13:15 ` [PATCH 01/12] lib: bitmap: Added alignment offset for bitmap_find_next_zero_area() Marek Szyprowski
2011-03-31 13:15 ` [PATCH 02/12] lib: genalloc: Generic allocator improvements Marek Szyprowski
2011-03-31 13:15 ` [PATCH 03/12] mm: move some functions from memory_hotplug.c to page_isolation.c Marek Szyprowski
2011-03-31 13:16 ` [PATCH 04/12] mm: alloc_contig_freed_pages() added Marek Szyprowski
2011-03-31 15:58 ` Dave Hansen [this message]
2011-03-31 19:24 ` Steven Rostedt
2011-03-31 20:33 ` Dave Hansen
2011-03-31 21:09 ` Michal Nazarewicz
2011-03-31 21:14 ` Dave Hansen
2011-03-31 22:18 ` Michal Nazarewicz
2011-03-31 22:26 ` Dave Hansen
2011-03-31 22:51 ` Michal Nazarewicz
2011-04-01 14:03 ` Dave Hansen
2011-04-04 13:15 ` Michal Nazarewicz
2011-04-05 7:23 ` Marek Szyprowski
2011-03-31 13:16 ` [PATCH 05/12] mm: alloc_contig_range() added Marek Szyprowski
2011-03-31 16:02 ` Dave Hansen
2011-03-31 16:26 ` Michal Nazarewicz
2011-03-31 19:28 ` Steven Rostedt
2011-03-31 19:52 ` Michal Nazarewicz
2011-03-31 20:28 ` Dave Hansen
2011-03-31 21:17 ` Michal Nazarewicz
2011-03-31 19:26 ` Steven Rostedt
2011-03-31 16:04 ` Dave Hansen
2011-03-31 13:16 ` [PATCH 06/12] mm: cma: Contiguous Memory Allocator added Marek Szyprowski
2011-03-31 13:16 ` [PATCH 07/12] mm: MIGRATE_CMA migration type added Marek Szyprowski
2011-03-31 13:16 ` [PATCH 08/12] mm: MIGRATE_CMA isolation functions added Marek Szyprowski
2011-03-31 13:16 ` [PATCH 09/12] mm: MIGRATE_CMA support added to CMA Marek Szyprowski
2011-03-31 13:16 ` [PATCH 10/12] mm: cma: add CMA 'regions style' API (for testing) Marek Szyprowski
2011-03-31 13:16 ` [PATCH 11/12] v4l: videobuf2: add CMA allocator " Marek Szyprowski
2011-03-31 13:16 ` [PATCH 12/12] ARM: S5PC110: Added CMA regions to Aquila and Goni boards Marek Szyprowski
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=1301587083.31087.1032.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.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;
as well as URLs for NNTP newsgroup(s).