[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0901292047400.3150@localhost.localdomain>
Date: Thu, 29 Jan 2009 20:49:52 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Lee Schermerhorn <Lee.Schermerhorn@...com>
cc: Hugh Dickins <hugh@...itas.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Maksim Yevmenkin <maksim.yevmenkin@...il.com>,
Nick Piggin <npiggin@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>, will@...wder-design.com,
Rik van Riel <riel@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED
file segments
On Thu, 29 Jan 2009, Lee Schermerhorn wrote:
>
> Just want to note that install_special_mappings()--used for, e.g., the
> vdso--sets VM_DONTEXPAND [one of the VM_SPECIAL flags] which, if we want
> to prevent merging, makes a lot of sense to me.
Yes. VM_DONTEXPAND in many ways really fits the "don't merge" thing,
because the whole mremap() VM expansion thing is really equivalent to this
explicit merge.
> It appears that get_user_pages() will balk at addresses in vmas with
> VM_IO [and VM_PFNMAP] which might not be what one wants. For example,
> you can't pre-populate the ptes via make_pages_present() with this flag.
Well, anybody who plays games with vm_pgoff really _should_ be VM_IO. I
don't see any real reason for it except for having a very special IO
mapping. Of course, you quite possibly _also_ want VM_DONTEXPAND.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists