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 '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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox