From: 'David Gibson' <david@gibson.dropbear.id.au>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Christoph Lameter' <clameter@sgi.com>,
'Andrew Morton' <akpm@osdl.org>,
'Hugh Dickins' <hugh@veritas.com>,
bill.irwin@oracle.com, 'Adam Litke' <agl@us.ibm.com>,
linux-mm@kvack.org
Subject: Re: [hugepage] Fix unmap_and_free_vma backout path
Date: Tue, 14 Nov 2006 11:19:51 +1100 [thread overview]
Message-ID: <20061114001951.GE13060@localhost.localdomain> (raw)
In-Reply-To: <000301c706f6$4ae26160$a081030a@amr.corp.intel.com>
On Sun, Nov 12, 2006 at 11:35:28PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Sunday, November 12, 2006 10:23 PM
> > > > Probably, yes, although it's yet another "if (hugepage)
> > > > specialcase()". But I still think we want the above patch as well.
> > > > It will make sure we correctly back out from any other possible
> > > > failure cases in hugetlbfs_file_mmap() - ones I haven't thought of, or
> > > > which get added later.
> > >
> > >
> > > Something like this? I haven't tested it yet. But looks plausible
> > > because we already have if is_file_hugepages() in the generic path.
> >
> > Um.. if you're going to test pgoff here, you should also test the
> > address.
>
> prepare_hugepage_range() should catch misaligned memory address, right?
> What more does get_unmapped_area() need to test?
>
>
> > Oh, and that point is too late to catch MAP_FIXED mappings.
>
> I don't understand what you mean by that.
Sorry, old data. I was thinking of the old get_unmapped_area() which
had entirely separate paths for MAP_FIXED and otherwise. And I had my
sense inverted as well.
It used to be that prepare_hugepage_range() was called *only* in the
MAP_FIXED case (it being assumed that the hugetlb specific
get_unmapped_area call would do any necessary preparation).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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>
prev parent reply other threads:[~2006-11-14 0:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-13 5:13 [hugepage] Fix unmap_and_free_vma backout path 'David Gibson'
2006-11-13 5:29 ` Christoph Lameter
2006-11-13 5:57 ` 'David Gibson'
2006-11-13 6:03 ` Chen, Kenneth W
2006-11-13 6:22 ` 'David Gibson'
2006-11-13 7:35 ` Chen, Kenneth W
2006-11-13 17:00 ` Hugh Dickins
2006-11-13 17:38 ` Chen, Kenneth W
2006-11-13 20:34 ` Adam Litke
2006-11-13 20:41 ` Hugh Dickins
2006-11-13 22:07 ` Adam Litke
2006-11-13 23:53 ` 'David Gibson'
2006-11-14 23:48 ` Bill Irwin
2006-11-14 0:19 ` 'David Gibson' [this message]
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=20061114001951.GE13060@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=bill.irwin@oracle.com \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=kenneth.w.chen@intel.com \
--cc=linux-mm@kvack.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 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.