linux.git/mm, branch v2.6.15 Linux kernel source tree [PATCH] Make sure interleave masks have at least one node set 2006-01-03T01:01:42+00:00 Andi Kleen ak@suse.de 2006-01-02T23:07:28+00:00 8f493d797bc1fe470377adc9d8775845427e240e Otherwise a bad mem policy system call can confuse the interleaving code into referencing undefined nodes. Originally reported by Doug Chapman I was told it's CVE-2005-3358 (one has to love these security people - they make everything sound important) Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Otherwise a bad mem policy system call can confuse the interleaving
code into referencing undefined nodes.

Originally reported by Doug Chapman

I was told it's CVE-2005-3358
(one has to love these security people - they make everything sound important)

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make sure we copy pages inserted with "vm_insert_page()" on fork 2005-12-16T18:21:23+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-16T18:21:23+00:00 4d7672b46244abffea1953e55688c0ea143dd617 The logic that decides that a fork() might be able to avoid copying a VM area when it can be re-created by page faults didn't know about the new vm_insert_page() case. Also make some things a bit more anal wrt VM_PFNMAP. Pointed out by Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The logic that decides that a fork() might be able to avoid copying a VM
area when it can be re-created by page faults didn't know about the new
vm_insert_page() case.

Also make some things a bit more anal wrt VM_PFNMAP.

Pointed out by Hugh Dickins <hugh@veritas.com>

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] missing prototype (mm/page_alloc.c) 2005-12-15T18:04:30+00:00 Al Viro viro@ftp.linux.org.uk 2005-12-15T09:18:25+00:00 78d9955bb06493e7bd78e43dfdc17fb5f1dc59b6 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Fix calculation of grow_pgdat_span() in mm/memory_hotplug.c 2005-12-14T05:18:16+00:00 Yasunori Goto y-goto@jp.fujitsu.com 2005-12-14T01:03:37+00:00 118c71bcacce82a4317c9bd99c6a15af14020aee The calculation for node_spanned_pages at grow_pgdat_span() is clearly wrong. This is patch for it. (Please see grow_zone_span() to compare. It is correct.) Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Acked-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The calculation for node_spanned_pages at grow_pgdat_span() is clearly
wrong.  This is patch for it.

(Please see grow_zone_span() to compare. It is correct.)

Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Acked-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
get_user_pages: don't try to follow PFNMAP pages 2005-12-13T00:24:33+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-13T00:24:33+00:00 1ff8038988adecfde71d82c0597727fc239d4e8c Nick Piggin points out that a few drivers play games with VM_IO (why? who knows..) and thus a pfn-remapped area may not have that bit set even if remap_pfn_range() set it originally. So make it explicit in get_user_pages() that we don't follow VM_PFNMAP pages, since pretty much by definition they do not have a "struct page" associated with them. Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Nick Piggin points out that a few drivers play games with VM_IO (why?
who knows..) and thus a pfn-remapped area may not have that bit set even
if remap_pfn_range() set it originally.

So make it explicit in get_user_pages() that we don't follow VM_PFNMAP
pages, since pretty much by definition they do not have a "struct page"
associated with them.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] fix in __alloc_bootmem_core() when there is no free page in first node's memory 2005-12-12T16:57:45+00:00 Haren Myneni haren@us.ibm.com 2005-12-12T08:37:39+00:00 66d43e98ea6ff291cd4e524386bfb99105feb180 Hitting BUG_ON() in __alloc_bootmem_core() when there is no free page available in the first node's memory. For the case of kdump on PPC64 (Power 4 machine), the captured kernel is used two memory regions - memory for TCE tables (tce-base and tce-size at top of RAM and reserved) and captured kernel memory region (crashk_base and crashk_size). Since we reserve the memory for the first node, we should be returning from __alloc_bootmem_core() to search for the next node (pg_dat). Currently, find_next_zero_bit() is returning the n^th bit (eidx) when there is no free page. Then, test_bit() is failed since we set 0xff only for the actual size initially (init_bootmem_core()) even though rounded up to one page for bdata->node_bootmem_map. We are hitting the BUG_ON after failing to enter second "for" loop. Signed-off-by: Haren Myneni <haren@us.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Hitting BUG_ON() in __alloc_bootmem_core() when there is no free page
available in the first node's memory.  For the case of kdump on PPC64
(Power 4 machine), the captured kernel is used two memory regions - memory
for TCE tables (tce-base and tce-size at top of RAM and reserved) and
captured kernel memory region (crashk_base and crashk_size).  Since we
reserve the memory for the first node, we should be returning from
__alloc_bootmem_core() to search for the next node (pg_dat).

Currently, find_next_zero_bit() is returning the n^th bit (eidx) when there
is no free page.  Then, test_bit() is failed since we set 0xff only for the
actual size initially (init_bootmem_core()) even though rounded up to one
page for bdata->node_bootmem_map.  We are hitting the BUG_ON after failing
to enter second "for" loop.

Signed-off-by: Haren Myneni <haren@us.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Allow arbitrary read-only shared pfn-remapping too 2005-12-12T04:38:17+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-12T04:38:17+00:00 67121172f9753f38689651b613a4850e0e75876f The VM layer (for historical reasons) turns a read-only shared mmap into a private-like mapping with the VM_MAYWRITE bit clear. Thus checking just VM_SHARED isn't actually sufficient. So use a trivial helper function for the cases where we wanted to inquire if a mapping was COW-like or not. Moo! Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
The VM layer (for historical reasons) turns a read-only shared mmap into
a private-like mapping with the VM_MAYWRITE bit clear.  Thus checking
just VM_SHARED isn't actually sufficient.

So use a trivial helper function for the cases where we wanted to inquire
if a mapping was COW-like or not.

Moo!

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove (at least temporarily) the "incomplete PFN mapping" support 2005-12-12T03:57:52+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-12T03:57:52+00:00 7fc7e2eeecb599ba719c4c4503100fc8cd6a6920 With the previous commit, we can handle arbitrary shared re-mappings even without this complexity, and since the only known private mappings are for strange users of /dev/mem (which never create an incomplete one), there seems to be no reason to support it. Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
With the previous commit, we can handle arbitrary shared re-mappings
even without this complexity, and since the only known private mappings
are for strange users of /dev/mem (which never create an incomplete one),
there seems to be no reason to support it.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Allow arbitrary shared PFNMAP's 2005-12-12T03:46:02+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-12T03:46:02+00:00 fb155c1619f056ae9765eed272cd6aba6e1a7399 A shared mapping doesn't cause COW-pages, so we don't need to worry about the whole vm_pgoff logic to decide if a PFN-remapped page has gone through COW or not. This makes it possible to entirely avoid the special "partial remapping" logic for the common case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
A shared mapping doesn't cause COW-pages, so we don't need to worry
about the whole vm_pgoff logic to decide if a PFN-remapped page has
gone through COW or not.

This makes it possible to entirely avoid the special "partial remapping"
logic for the common case.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make vm_insert_page() available to NVidia module 2005-12-04T04:48:11+00:00 Linus Torvalds torvalds@g5.osdl.org 2005-12-04T04:48:11+00:00 e3c3374fbf7efe9487edc53cd10436ed641983aa It used to use remap_pfn_range(), which wasn't GPL-only either, and the new interface is actually simpler and does more checking, so we shouldn't unnecessarily discourage people from switching over. Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
It used to use remap_pfn_range(), which wasn't GPL-only either, and the
new interface is actually simpler and does more checking, so we
shouldn't unnecessarily discourage people from switching over.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>