linux-toradex.git/mm/madvise.c, branch v2.6.30

Revert "Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions"

2009-05-13T15:29:12+00:00

This reverts commit a425a638c858fd10370b573bde81df3ba500e271.

Now that the previous commit removed the "readpage" actor for hugetlb
files, read-ahead will no longer mess up the mapping, and there's no
longer any reason to treat hugetlbfs mappings specially.

Tested-and-acked-by: Mel Gorman 
Signed-off-by: Linus Torvalds

Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions

2009-05-05T21:37:58+00:00

madvise(MADV_WILLNEED) forces page cache readahead on a range of memory
backed by a file.  The assumption is made that the page required is
order-0 and "normal" page cache.

On hugetlbfs, this assumption is not true and order-0 pages are
allocated and inserted into the hugetlbfs page cache.  This leaks
hugetlbfs page reservations and can cause BUGs to trigger related to
corrupted page tables.

This patch causes MADV_WILLNEED to be ignored for hugetlbfs-backed
regions.

Signed-off-by: Mel Gorman 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

[CVE-2009-0029] System call wrappers part 14

2009-01-14T13:15:24+00:00

Signed-off-by: Heiko Carstens

madvise: update function comment of madvise_dontneed

2008-07-30T16:41:45+00:00

Signed-off-by: Fernando Luis Vazquez Cao 
Cc: Hugh Dickins 
Cc: Nick Piggin 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

xip: support non-struct page backed memory

2008-04-28T15:58:23+00:00

Convert XIP to support non-struct page backed memory, using VM_MIXEDMAP for
the user mappings.

This requires the get_xip_page API to be changed to an address based one.
Improve the API layering a little bit too, while we're here.

This is required in order to support XIP filesystems on memory that isn't
backed with struct page (but memory with struct page is still supported too).

Signed-off-by: Nick Piggin 
Acked-by: Carsten Otte 
Cc: Jared Hulbert 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

speed up madvise_need_mmap_write() usage

2007-07-16T16:05:36+00:00

In the new madvise_need_mmap_write() call we can avoid an extra case
statement and function call as follows.

Signed-off-by: Jason Baron 
Cc: Nishanth Aravamudan 
Cc: Christoph Hellwig 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Detach sched.h from mm.h

2007-05-21T16:18:19+00:00

First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.

This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes can_do_mlock() normal function in mm/mlock.c
c) exports can_do_mlock() to not break compilation
d) adds sched.h inclusions back to files that were getting it indirectly.
e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
   getting them indirectly

Net result is:
a) mm.h users would get less code to open, read, preprocess, parse, ... if
   they don't need sched.h
b) sched.h stops being dependency for significant number of files:
   on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
   after patch it's only 3744 (-8.3%).

Cross-compile tested on

	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
	alpha alpha-up
	arm
	i386 i386-up i386-defconfig i386-allnoconfig
	ia64 ia64-up
	m68k
	mips
	parisc parisc-up
	powerpc powerpc-up
	s390 s390-up
	sparc sparc-up
	sparc64 sparc64-up
	um-x86_64
	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

as well as my two usual configs.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds

mm: madvise avoid exclusive mmap_sem

2007-05-07T19:12:54+00:00

Avoid down_write of the mmap_sem in madvise when we can help it.

Acked-by: Hugh Dickins 
Signed-off-by: Nick Piggin 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] holepunch: fix mmap_sem i_mutex deadlock

2007-03-29T15:22:26+00:00

sys_madvise has down_write of mmap_sem, then madvise_remove calls
vmtruncate_range which takes i_mutex and i_alloc_sem: no, we can easily devise
deadlocks from that ordering.

madvise_remove drop mmap_sem while calling vmtruncate_range: luckily, since
madvise_remove doesn't split or merge vmas, it's easy to handle this case with
a NULL prev, without restructuring sys_madvise.  (Though sad to retake
mmap_sem when it's unlikely to be needed, and certainly down_read is
sufficient for MADV_REMOVE, unlike the other madvices.)

Signed-off-by: Hugh Dickins 
Cc: Miklos Szeredi 
Cc: Badari Pulavarty 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] mm: fix madvise infinine loop

2007-03-17T02:25:04+00:00

madvise(MADV_REMOVE) can go into an infinite loop or cause an oops if the
call covers a region from the start of a vma, and extending past that vma.

Signed-off-by: Nick Piggin 
Cc: Badari Pulavarty 
Acked-by: Hugh Dickins 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds