user/sven/linux.git/include/linux/mman.h, branch v3.0.42

mm: fix Committed_AS underflow on large NR_CPUS environment

2009-05-02T22:36:10Z

The Committed_AS field can underflow in certain situations: > # while true; do cat /proc/meminfo | grep _AS; sleep 1; done | uniq -c > 1 Committed_AS: 18446744073709323392 kB > 11 Committed_AS: 18446744073709455488 kB > 6 Committed_AS: 35136 kB > 5 Committed_AS: 18446744073709454400 kB > 7 Committed_AS: 35904 kB > 3 Committed_AS: 18446744073709453248 kB > 2 Committed_AS: 34752 kB > 9 Committed_AS: 18446744073709453248 kB > 8 Committed_AS: 34752 kB > 3 Committed_AS: 18446744073709320960 kB > 7 Committed_AS: 18446744073709454080 kB > 3 Committed_AS: 18446744073709320960 kB > 5 Committed_AS: 18446744073709454080 kB > 6 Committed_AS: 18446744073709320960 kB Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does not check for underflow. But NR_CPUS proportional isn't good calculation. In general, possibility of lock contention is proportional to the number of online cpus, not theorical maximum cpus (NR_CPUS). The current kernel has generic percpu-counter stuff. using it is right way. it makes code simplify and percpu_counter_read_positive() don't make underflow issue. Reported-by: Dave Hansen Signed-off-by: KOSAKI Motohiro Cc: Eric B Munson Cc: Mel Gorman Cc: Christoph Lameter Cc: [All kernel versions] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm: Allow architectures to define additional protection bits

2008-07-09T06:30:45Z

This patch allows architectures to define functions to deal with additional protections bits for mmap() and mprotect(). arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot arch_validate_prot() checks for valid values of the protection bits Note: vm_get_page_prot() is now pretty ugly, but the generated code should be identical for architectures that don't define additional protection bits. Signed-off-by: Dave Kleikamp Acked-by: Andrew Morton Acked-by: Hugh Dickins Signed-off-by: Benjamin Herrenschmidt

mm: fix atomic_t overflow in vm

2008-05-24T16:56:09Z

The atomic_t type is 32bit but a 64bit system can have more than 2^32 pages of virtual address space available. Without this we overflow on ludicrously large mappings Signed-off-by: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Don't include linux/config.h from anywhere else in include/

2006-04-26T11:56:16Z

Signed-off-by: David Woodhouse

Sanitise linux/mman.h for userspace consumption

2006-04-25T13:18:07Z

It only really needs to define a few constants and include when it's used by userspace. Move the rest within #ifdef __KERNEL__ Signed-off-by: David Woodhouse

[PATCH] overcommit symbolic constants

2004-09-30T01:41:37Z

Played a bit with overcommit the past hour. Am not entirely satisfied with the no overcommit mode 2 - programs segfault when the system is close to that boundary. So, instead of the somewhat larger patch that I planned to send, just symbolic names for the modes.

[PATCH] document the macro for translating PROT_ to VM_ bits

2003-10-05T04:03:09Z

From: Muli Ben-Yehuda Shed some much-needed light.

[PATCH] Common PROT_xxx -> VM_xxx mapping

2003-09-05T04:42:15Z

This moves the mapping of PROT_* bits to VM_* bits from mmap.c to the common header file . The mapping is needed for mprotect too.

[PATCH] Security hook for vm_enough_memory

2003-07-02T15:49:35Z

From: Stephen Smalley This patch against 2.5.73 replaces vm_enough_memory with a security hook per Alan Cox's suggestion so that security modules can completely replace the logic if desired. Note that the patch changes the interface to follow the convention of the other security hooks, i.e. return 0 if ok or -errno on failure (-ENOMEM in this case) rather than returning a boolean. It also exports various variables and functions required for the vm_enough_memory logic.

[PATCH] speed up vm_enough_memory()

2003-03-22T15:33:34Z

This function is called a lot. Every brk(). The atomic_add() against a global counter hurts on large SMP machines. The patch simply reduces the rate at which that atomic operation is performed, by accumulating a per-cpu count which is spilled into the global counter when the local counter overflows. It trades off efficiency for a little inaccuracy. I tried various implementations involving kmalloc_percpu() and open-coded per-cpu arrays in a generic "per-cpu counter" thing. They all were surprisingly sucky - the additional cache misses involved in walking the more complex data structures really showed up.