ALSA: Fix SG-buffer DMA with non-coherent architectures

[pandora-kernel.git] / mm / Kconfig

diff --git a/mm/Kconfig b/mm/Kconfig
index c2b57d8..c948d4c 100644 (file)
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -128,11 +128,11 @@ config SPARSEMEM_VMEMMAP
 config MEMORY_HOTPLUG
        bool "Allow for memory hot-add"
        depends on SPARSEMEM || X86_64_ACPI_NUMA
-       depends on HOTPLUG && !HIBERNATION && ARCH_ENABLE_MEMORY_HOTPLUG
+       depends on HOTPLUG && !(HIBERNATION && !S390) && ARCH_ENABLE_MEMORY_HOTPLUG
        depends on (IA64 || X86 || PPC64 || SUPERH || S390)
 
 comment "Memory hotplug is currently incompatible with Software Suspend"
-       depends on SPARSEMEM && HOTPLUG && HIBERNATION
+       depends on SPARSEMEM && HOTPLUG && HIBERNATION && !S390
 
 config MEMORY_HOTPLUG_SPARSE
        def_bool y
@@ -203,29 +203,36 @@ config VIRT_TO_BUS
        def_bool y
        depends on !ARCH_NO_VIRT_TO_BUS
 
-config UNEVICTABLE_LRU
-       bool "Add LRU list to track non-evictable pages"
-       default y
-       help
-         Keeps unevictable pages off of the active and inactive pageout
-         lists, so kswapd will not waste CPU time or have its balancing
-         algorithms thrown off by scanning these pages.  Selecting this
-         will use one page flag and increase the code size a little,
-         say Y unless you know what you are doing.
-
-         See Documentation/vm/unevictable-lru.txt for more information.
-
 config HAVE_MLOCK
        bool
        default y if MMU=y
 
 config HAVE_MLOCKED_PAGE_BIT
        bool
-       default y if HAVE_MLOCK=y && UNEVICTABLE_LRU=y
+       default y if HAVE_MLOCK=y
 
 config MMU_NOTIFIER
        bool
 
+config DEFAULT_MMAP_MIN_ADDR
+        int "Low address space to protect from user allocation"
+        default 4096
+        help
+         This is the portion of low virtual memory which should be protected
+         from userspace allocation.  Keeping a user from writing to low pages
+         can help reduce the impact of kernel NULL pointer bugs.
+
+         For most ia64, ppc64 and x86 users with lots of address space
+         a value of 65536 is reasonable and should cause no problems.
+         On arm and other archs it should not be higher than 32768.
+         Programs which use vm86 functionality would either need additional
+         permissions from either the LSM or the capabilities module or have
+         this protection disabled.
+
+         This value can be changed after boot using the
+         /proc/sys/vm/mmap_min_addr tunable.
+
+
 config NOMMU_INITIAL_TRIM_EXCESS
        int "Turn on mmap() excess space trimming before booting"
        depends on !MMU