kernel/mm, branch linux-2.6.19.y

[PATCH] Don't allow the stack to grow into hugetlb reserved regions

2007-02-05T16:31:44Z

When expanding the stack, we don't currently check if the VMA will cross into an area of the address space that is reserved for hugetlb pages. Subsequent faults on the expanded portion of such a VMA will confuse the low-level MMU code, resulting in an OOPS. Check for this. Signed-off-by: Adam Litke Cc: David Gibson Cc: William Lee Irwin III Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] Check for populated zone in __drain_pages

2007-02-05T16:31:39Z

Both process_zones() and drain_node_pages() check for populated zones before touching pagesets. However, __drain_pages does not do so, This may result in a NULL pointer dereference for pagesets in unpopulated zones if a NUMA setup is combined with cpu hotplug. Initially the unpopulated zone has the pcp pointers pointing to the boot pagesets. Since the zone is not populated the boot pageset pointers will not be changed during page allocator and slab bootstrap. If a cpu is later brought down (first call to __drain_pages()) then the pcp pointers for cpus in unpopulated zones are set to NULL since __drain_pages does not first check for an unpopulated zone. If the cpu is then brought up again then we call process_zones() which will ignore the unpopulated zone. So the pageset pointers will still be NULL. If the cpu is then again brought down then __drain_pages will attempt to drain pages by following the NULL pageset pointer for unpopulated zones. Signed-off-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] Fix up page_mkclean_one(): virtual caches, s390

2007-01-10T19:05:23Z

- add flush_cache_page() for all those virtual indexed cache architectures. - handle s390. Signed-off-by: Peter Zijlstra Signed-off-by: Linus Torvalds [chrisw: fold in d6e88e671ac1] Signed-off-by: Chris Wright

[PATCH] Fix incorrect user space access locking in mincore() (CVE-2006-4814)

2007-01-10T19:05:23Z

Doug Chapman noticed that mincore() will doa "copy_to_user()" of the result while holding the mmap semaphore for reading, which is a big no-no. While a recursive read-lock on a semaphore in the case of a page fault happens to work, we don't actually allow them due to deadlock schenarios with writers due to fairness issues. Doug and Marcel sent in a patch to fix it, but I decided to just rewrite the mess instead - not just fixing the locking problem, but making the code smaller and (imho) much easier to understand. Cc: Doug Chapman Cc: Marcel Holtmann Cc: Hugh Dickins Cc: Andrew Morton [chrisw: fold in subsequent fix: 4fb23e439ce0] Acked-by: Hugh Dickins [chrisw: fold in subsequent fix: 825020c3866e] Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] fix OOM killing of swapoff

2007-01-10T19:05:23Z

These days, if you swapoff when there isn't enough memory, OOM killer gives "BUG: scheduling while atomic" and the machine hangs: badness() needs to do its PF_SWAPOFF return after the task_unlock (tasklist_lock is also held here, so p isn't going to be freed: PF_SWAPOFF might get turned off at any moment, but that doesn't really matter). Signed-off-by: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] VM: Fix nasty and subtle race in shared mmap'ed page writeback

2007-01-10T19:05:22Z

The VM layer (on the face of it, fairly reasonably) expected that when it does a ->writepage() call to the filesystem, it would write out the full page at that point in time. Especially since it had earlier marked the whole page dirty with "set_page_dirty()". But that isn't actually the case: ->writepage() does not actually write a page, it writes the parts of the page that have been explicitly marked dirty before, *and* that had not got written out for other reasons since the last time we told it they were dirty. That last caveat is the important one. Which _most_ of the time ends up being the whole page (since we had called "set_page_dirty()" on the page earlier), but if the filesystem had done any dirty flushing of its own (for example, to honor some internal write ordering guarantees), it might end up doing only a partial page IO (or none at all) when ->writepage() is actually called. That is the correct thing in general (since we actually often _want_ only the known-dirty parts of the page to be written out), but the shared dirty page handling had implicitly forgotten about these details, and had a number of cases where it was doing just the "->writepage()" part, without telling the low-level filesystem that the whole page might have been re-dirtied as part of being mapped writably into user space. Since most of the time the FS did actually write out the full page, we didn't notice this for a loong time, and this needed some really odd patterns to trigger. But it caused occasional corruption with rtorrent and with the Debian "apt" database, because both use shared mmaps to update the end result. This fixes it. Finally. After way too much hair-pulling. Acked-by: Nick Piggin Acked-by: Martin J. Bligh Acked-by: Martin Michlmayr Acked-by: Martin Johansson Acked-by: Ingo Molnar Acked-by: Andrei Popa Cc: High Dickins Cc: Andrew Morton , Cc: Peter Zijlstra Cc: Segher Boessenkool Cc: David Miller Cc: Arjan van de Ven Cc: Gordon Farquharson Cc: Guillaume Chazarain Cc: Theodore Tso Cc: Kenneth Cheng Cc: Tobias Diedrich Signed-off-by: Linus Torvalds [chrisw: backport to 2.6.19.1] Signed-off-by: Chris Wright

[PATCH] Buglet in vmscan.c

2007-01-10T19:05:20Z

Fix a rather obvious buglet. Noticed while instrumenting the VM using /proc/vmstat. Cc: Christoph Lameter Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] Fix for shmem_truncate_range() BUG_ON()

2007-01-10T19:05:19Z

Ran into BUG() while doing madvise(REMOVE) testing. If we are punching a hole into shared memory segment using madvise(REMOVE) and the entire hole is below the indirect blocks, we hit following assert. BUG_ON(limit <= SHMEM_NR_DIRECT); Signed-off-by: Badari Pulavarty Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] read_zero_pagealigned() locking fix

2007-01-10T19:05:17Z

Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by: Hugh Dickins Cc: Ramiro Voicu: Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] x86_64: fix bad page state in process 'swapper'

2006-11-23T17:30:38Z

find_min_pfn_for_node() and find_min_pfn_with_active_regions() both depend on a sorted early_node_map[]. However, sort_node_map() is being called after fin_min_pfn_with_active_regions() in free_area_init_nodes(). In most cases, this is ok, but on at least one x86_64, the SRAT table caused the E820 ranges to be registered out of order. This gave the wrong values for the min PFN range resulting in some pages not being initialised. This patch sorts the early_node_map in find_min_pfn_for_node(). It has been boot tested on x86, x86_64, ppc64 and ia64. Signed-off-by: Mel Gorman Acked-by: Andre Noll Signed-off-by: Linus Torvalds