aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2005-10-30[PATCH] i386: use -mcpu, not -mtune, for GCCs older than 3.4Paolo 'Blaisorblade' Giarrusso
I just noted that -mtune is used, which is only supported on recent GCCs; by reading http://gcc.gnu.org/gcc-3.4/changes.html, you see "-mcpu has been renamed to -mtune.", so for GCC < 3.4 we're not using any specific tuning in the appropriate cases. However -mcpu is deprecated, so use -mtune when possible. This was introduced by commit e9d4dce954a60dc23dd1d967766ca2347b780e54 of the old tree (between 2.6.10-rc3 and 2.6.10) by Linus Torvalds, to remove the use of -march, since that could trigger gcc using SSE on its own. But no attention was used about using -mcpu vs. -mtune. And btw, the old 2.6.4 code (for instance) was: cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686) cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686) cflags-$(CONFIG_MPENTIUMM) += $(call check_gcc,-march=pentium3,-march=i686) cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686) Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] uml: remove old UM_FASTCALL, and make the thing work againPaolo 'Blaisorblade' Giarrusso
This was used in the old dark age of 2.4, ARCH_CFLAGS doesn't work any more since some time, and UM_FASTCALL was never used in 2.6. Instead, reintroduce the thing more properly now, directly in include/asm-um/linkage.h. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] uml: fix "reuse i386 cpu optimizations"Paolo 'Blaisorblade' Giarrusso
Remove RWSEM_GENERIC_SPINLOCK, it's now defined (only if needed) by the underlying arch/i386/Kconfig.cpu. Leave it only for x86_64. Even there, it's totally wrong, as they even have the code to support XCHG_ADD. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] uml: reuse i386 cpu-specific tuningPaolo 'Blaisorblade' Giarrusso
Make UML share the underlying cpu-specific tuning done on i386. Actually, for now many config options aren't used a lot - but that can be done later. Also, UML relies on GCC optimization for things like memcpy and such more than i386, so specifying the correct -march and -mtune should be enough. Later, we may want to correct some other stuff. For instance, since FPU context switching, for us, is done (at least partially, i.e. between our kernelspace and userspace) by the host, we may allow usage of FPU operations by GCC. This doesn't hold for kernelspace vs. kernelspace, but we don't support preemption. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] m32r: SMC91x driver updateHirokazu Takata
Update SMC91x driver for m32r. - Remove needless NONCACHE_OFFSET adjustment. > [PATCH 2.6.14-rc4] m32r: NONCACHE_OFFSET in _port2addr > Change _port2addr() not to add NONCACHE_OFFSET. > Adding NONCACHE_OFFSET requires needless address adjusting by a driver > using ioremap() like a SMC91x driver. - Fix lots of warnings as following: /usr/src/ctest/git/kernel/drivers/net/smc91x.c: In function `smc_reset': /usr/src/ctest/git/kernel/drivers/net/smc91x.c:324: warning: passing arg 2 of `_outw' makes integer from pointer without a cast /usr/src/ctest/git/kernel/drivers/net/smc91x.c:325: warning: passing arg 2 of `_outw' makes integer from pointer without a cast /usr/src/ctest/git/kernel/drivers/net/smc91x.c:341: warning: passing arg 2 of `_outw' makes integer from pointer without a cast /usr/src/ctest/git/kernel/drivers/net/smc91x.c:342: warning: passing arg 2 of `_outw' makes integer from pointer without a cast : /usr/src/ctest/git/kernel/drivers/net/smc91x.c:1915: warning: passing arg 1 of `_inw' makes integer from pointer without a cast /usr/src/ctest/git/kernel/drivers/net/smc91x.c:1915: warning: passing arg 1 of `_inw' makes integer from pointer without a cast Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] m32r: NONCACHE_OFFSET in _port2addrHirokazu Takata
Change _port2addr() not to add NONCACHE_OFFSET. Adding NONCACHE_OFFSET requires needless address adjusting by a driver using ioremap() like a SMC91x driver. Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] m32r: fix #if warningsHirokazu Takata
Fix warnings for #if directives. Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] m32r: remove unused instructionsHirokazu Takata
Remove unused instructions for debugging. Signed-off-by: Naoto Sugai <sugai@isl.melco.co.jp> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] swsusp: rework memory freeing on resumeRafael J. Wysocki
The following patch makes swsusp use the PG_nosave and PG_nosave_free flags to mark pages that should be freed in case of an error during resume. This allows us to simplify the code and to use swsusp_free() in all of the swsusp's resume error paths, which makes them actually work. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] create and destroy cache sysfs entries based on cpu notifiersAshok Raj
cpu cache entries should be populated only when cpu is online and removed when they are logically offlined. Without which entries are not removed when cpu is offlined, or dont appear when we boot with maxcpus=1 and then kick the rest of the cpus via echo 1 to the sysfs online file. - Changed __devinit to __cpuinit for consistency. - Changed sysfs_driver_register to register_cpu_notifier. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Zwane Mwaikambo <zwane@holomorphy.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386: srat on non-acpi hw fixMagnus Damm
This patch adds a check for the return value of acpi_find_root_pointer(). Without this patch systems without ACPI support such as QEMU crashes when booting a NUMA kernel with CONFIG_ACPI_SRAT=y. Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386 mpparse: Only ignore lapic information we can't storeEric W. Biederman
After staring at mpparse.c for a little longer I noticed that when we hit our limit of num_processors we are filtering out information about other processors that we can still store. This patch just reorders the code so we store everything we can. This should avoid the incorrect warning about our boot CPU not being listed by the BIOS that we are now getting in the kexec on panic case, and it should allow us to detect all apicid conflicts even when our physical number of cpus exceeds maxcpus. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] kdump/i386: apic verification failure fixVivek Goyal
o Removes the unnecessary call to local_irq_disable(). o Kdump was failing while second kernel was coming up. Check for presence of boot cpu apic id was failing in (apic_id_registered), hence hitting BUG(). o This should not have failed because before calling setup_local_APIC(), it is ensured that even if BIOS has not reported boot cpu, then hard set the prence of it. Problem happens because of usage of hard_smp_processor_id() which is hardcoded to zero in case of non SMP kernel. In kdump case second kernel can boot on a cpu whose boot cpu id is not zero. o Using boot_cpu_physical_apicid instead to hard set the presence of boot cpu. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] Clean up mtrr compat ioctl codeBrian Gerst
Handle 32-bit mtrr ioctls in the mtrr driver instead of the ia32 compatability layer. Signed-off-by: Brian Gerst <bgerst@didntduck.org> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: vmx cpu feature detectionKamble, Nitin A
If VMX feature is available in the CPU, this patch will make it visible in the /proc/cpuinfo with the cpuid detection. Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386 kexec-on-panic: Don't shutdown the apics.Eric W. Biederman
It is dangerous to shutdown the apics in machine_crash_shutdown. With my previous patch to initialize apics in init_IRQ we should be able to boot a kernel without this. As long as we reinitialize the APICs we don't care what state they were in during bootup. This should make machine_crash_shutdown noticeably more reliable. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386: move apic init in init_IRQsEric W. Biederman
All kinds of ugliness exists because we don't initialize the apics during init_IRQs. - We calibrate jiffies in non apic mode even when we are using apics. - We have to have special code to initialize the apics when non-smp. - The legacy i8259 must exist and be setup correctly, even when we won't use it past initialization. - The kexec on panic code must restore the state of the io_apics. - init/main.c needs a special case for !smp smp_init on x86 In addition to pure code movement I needed a couple of non-obvious changes: - Move setup_boot_APIC_clock into APIC_late_time_init for simplicity. - Use cpu_khz to generate a better approximation of loops_per_jiffies so I can verify the timer interrupt is working. - Call setup_apic_nmi_watchdog again after cpu_khz is initialized on the boot cpu. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386 nmi_watchdog: Merge check_nmi_watchdog fixes from x86_64Eric W. Biederman
The per cpu nmi watchdog timer is based on an event counter. idle cpus don't generate events so the NMI watchdog doesn't fire and the test to see if the watchdog is working fails. - Add nmi_cpu_busy so idle cpus don't mess up the test. - kmalloc prev_nmi_count to keep kernel stack usage bounded. - Improve the error message on failure so there is enough information to debug problems. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386 io_apic.c: Memorize at bootup where the i8259 is connectedEric W. Biederman
Currently we attempt to restore virtual wire mode on reboot, which only works if we can figure out where the i8259 is connected. This is very useful when we kexec another kernel and likely helpful when dealing with a BIOS that make assumptions about how the system is setup. Since the acpi MADT table does not provide the location where the i8259 is connected we have to look at the hardware to figure it out. Most systems have the i8259 connected the local apic of the cpu so won't be affected but people running Opteron and some serverworks chipsets should be able to use kexec now. In addition this patch removes the hard coded assumption that the io_apic that delivers isa interrups is always known to the kernel as io_apic 0. As there does not appear to be anything to guarantee that assumption is true. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] ES7000 platform updateNatalie.Protasevich@unisys.com
This is platform code update for ES7000: disables IRQ overrides for the recent ES7000 (Rascal/Zorro), cleans up the compile warning. The patch only affects the ES7000 subarch. Signed-off-by: <Natalie.Protasevich@unisys.com> Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: when L3 is present show its size in /proc/cpuinfoVenkatesh Pallipadi
The code that prints the cache size assumes that L3 always lives in chipset and is shared across CPUs. Which is not really true. I think all the cachesizes reported by cpuid are in the processor itself. The attached patch changes the code to reflect that. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] fixup bogus e820 entry with mem=Dave Hansen
This was reported because someone was getting oopses reading /proc/iomem. It was tracked down to a zero-sized 'struct resource' entry which was located right at 4GB. You need two conditions to hit this bug: a BIOS E820_RAM area starting at exactly the boundary where you specify mem= (to get a zero-sized entry), and for the legacy_init_iomem_resources() loop to skip that resource (which only happens at exactly 4G). I think the killing zero-sized e820 entry is the easiest way to fix this. Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] asus vt8235 router buggy bios workaroundaleksey_gorelov@phoenix.com
Hopefully fix http://bugzilla.kernel.org/show_bug.cgi?id=5235 Similar problem has been reported before here: http://groups.google.com/group/linux.kernel/browse_thread/thread/def4ca19dbc3cd4/5cffbf349f2c87a4?tvc=2&q=Aleksey+Gorelov&hl=en#5cffbf349f2c87a4 and was related to bug in BIOS reporting 82C686 router compatible to 586. I suspect BIOS on this board has similar issue: reports VT8235 router to be compatible with 586 one - which is obviously not true. Patch from the link above has already incorporated in both 2.6 & 2.4 series, but might not work in this particular case. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: bug fix in P6 Machine check initializationVenkatesh Pallipadi
Make P6 MCA initialization code complaint with guidelines in IA-32 SDM Vol3. Bank 0 control register should not be set by OS and clear status registers on all banks on reset. This will prevent false MCE alarms on the systems that has some non-MCE information left-over in MC0_STATUS on reboot. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: add an accessor function for getting the per-CPU gdtZachary Amsden
Add an accessor function for getting the per-CPU gdt. Callee must already have the CPU. Signed-off-by: Zachary Amsden <zach@vmware.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: bogus tls from gdtZachary Amsden
The per-CPU initialization code is copying in bogus data into thread->tls_array. Note that it copies &per_cpu(cpu_gdt_table, cpu), not &per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TLS_MIN). That is totally broken and unnecessary. Make the initialization explicitly NULL. Signed-off-by: Zachary Amsden <zach@vmware.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: hot plug CPU to support physical add of new processorsNatalie Protasevich
The patch allows physical bring-up of new processors (not initially present in the configuration) from facilities such as driver/utility implemented on a platform. The actual method of making processors available is up to the platform implementation. Signed-off-by: Natalie Protasevich <Natalie.Protasevich@unisys.com> Cc: Shaohua Li <shaohua.li@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Zwane Mwaikambo <zwane@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] intel_cacheinfo: remove MAX_CACHE_LEAVES limitSiddha, Suresh B
Initial internal version of Venki's cpuid(4) deterministic cache parameter identification patch used static arrays of size MAX_CACHE_LEAVES. Final patch which made to the base used dynamic array allocation, with this MAX_CACHE_LEAVES limit hunk still in place. cpuid(4) already has a mechanism to find out the number of cache levels implemented and there is no need for this hardcoded MAX_CACHE_LEAVES limit. So remove the MAX_CACHE_LEAVES limit from the routine which calculates the number of cache levels using cpuid(4) Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: initialise tss->io_bitmap_owner to somethingBart Oldeman
There exists a field io_bitmap_owner in the TSS that is only checked, but never set to anything else but NULL. Signed-off-by: Bart Oldeman <bartoldeman@users.sourceforge.net> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] FPU context corrupted after resumeShaohua Li
mxcsr_feature_mask_init isn't needed in suspend/resume time (we can use boot time mask). And actually it's harmful, as it clear task's saved fxsave in resume. This bug is widely seen by users using zsh. (akpm: my eyes. Fixed some surrounding whitespace mess) Signed-off-by: Shaohua Li<shaohua.li@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] x86: cmpxchg improvementsJan Beulich
This adjusts i386's cmpxchg patterns so that - for word and long cmpxchg-es the compiler can utilize all possible registers - cmpxchg8b gets disabled when the minimum specified hardware architectur doesn't support it (like was already happening for the byte, word, and long ones). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] i386 and x86_64 TSC set_cyc2ns_scale imprecisionMathieu Desnoyers
I just found out that some precision is unnecessarily lost in the arch/i386/kernel/timers/timer_tsc.c:set_cyc2ns_scale function. It uses a cpu_mhz parameter when it could use a cpu_khz. In the specific case of an Intel P4 running at 3001.171 Mhz, the truncation to 3001 Mhz leads to an imprecision of 19 microseconds per second : this is very sad for a timer with nearly nanosecond accuracy. Fix the x86_64 architecture too. Cc: george anzinger <george@mvista.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] CONFIG_IA32Brian Gerst
Add CONFIG_X86_32 for i386. This allows selecting options that only apply to 32-bit systems. (X86 && !X86_64) becomes X86_32 (X86 || X86_64) becomes X86 Signed-off-by: Brian Gerst <bgerst@didntduck.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] memory hotplug: ppc64 specific hot-add functionsDave Hansen
Here is a set of ppc64 specific patches that at least allow compilation/booting with the following configurations: FLATMEM SPARSEMEN SPARSEMEM + MEMORY_HOTPLUG Signed-off-by: Mike Kravetz <kravetz@us.ibm.com> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] memory hotplug: i386 addition functionsDave Hansen
Adds the necessary for non-NUMA hot-add of highmem to an existing zone on i386. Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] memory hotplug locking: node_size_lockDave Hansen
pgdat->node_size_lock is basically only neeeded in one place in the normal code: show_mem(), which is the arch-specific sysrq-m printing function. Strictly speaking, the architectures not doing memory hotplug do no need this locking in show_mem(). However, they are all included for completeness. This should also make any future consolidation of all of the implementations a little more straightforward. This lock is also held in the sparsemem code during a memory removal, as sections are invalidated. This is the place there pfn_valid() is made false for a memory area that's being removed. The lock is only required when doing pfn_valid() operations on memory which the user does not already have a reference on the page, such as in show_mem(). Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: split page table lockHugh Dickins
Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with a many-threaded application which concurrently initializes different parts of a large anonymous area. This patch corrects that, by using a separate spinlock per page table page, to guard the page table entries in that page, instead of using the mm's single page_table_lock. (But even then, page_table_lock is still used to guard page table allocation, and anon_vma allocation.) In this implementation, the spinlock is tucked inside the struct page of the page table page: with a BUILD_BUG_ON in case it overflows - which it would in the case of 32-bit PA-RISC with spinlock debugging enabled. Splitting the lock is not quite for free: another cacheline access. Ideally, I suppose we would use split ptlock only for multi-threaded processes on multi-cpu machines; but deciding that dynamically would have its own costs. So for now enable it by config, at some number of cpus - since the Kconfig language doesn't support inequalities, let preprocessor compare that with NR_CPUS. But I don't think it's worth being user-configurable: for good testing of both split and unsplit configs, split now at 4 cpus, and perhaps change that to 8 later. There is a benefit even for singly threaded processes: kswapd can be attacking one part of the mm while another part is busy faulting. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: uml kill unusedHugh Dickins
In worrying over the various pte operations in different architectures, I came across some unused functions in UML: remove mprotect_kernel_vm, protect_vm_page and addr_pte. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: uml pte atomicityHugh Dickins
There's usually a good reason when a pte is examined without the lock; but it makes me nervous when the pointer is dereferenced more than once. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: cris v32 mmu_context_lockHugh Dickins
The cris v32 switch_mm guards get_mmu_context with next->page_table_lock: good it's not really SMP yet, since get_mmu_context messes with global variables affecting other mms. Replace by global mmu_context_lock. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: parisc pte atomicityHugh Dickins
There's a worrying function translation_exists in parisc cacheflush.h, unaffected by split ptlock since flush_dcache_page is using it on some other mm, without any relevant lock. Oh well, make it a slightly more robust by factoring the pfn check within it. And it looked liable to confuse a camouflaged swap or file entry with a good pte: fix that too. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: arm ready for split ptlockHugh Dickins
Prepare arm for the split page_table_lock: three issues. Signal handling's preserve and restore of iwmmxt context currently involves reading and writing that context to and from user space, while holding page_table_lock to secure the user page(s) against kswapd. If we split the lock, then the structure might span two pages, secured by to read into and write from a kernel stack buffer, copying that out and in without locking (the structure is 160 bytes in size, and here we're near the top of the kernel stack). Or would the overhead be noticeable? arm_syscall's cmpxchg emulation use pte_offset_map_lock, instead of pte_offset_map and mm-wide page_table_lock; and strictly, it should now also take mmap_sem before descending to pmd, to guard against another thread munmapping, and the page table pulled out beneath this thread. Updated two comments in fault-armv.c. adjust_pte is interesting, since its modification of a pte in one part of the mm depends on the lock held when calling update_mmu_cache for a pte in some other part of that mm. This can't be done with a split page_table_lock (and we've already taken the lowest lock in the hierarchy here): so we'll have to disable split on arm, unless CONFIG_CPU_CACHE_VIPT to ensures adjust_pte never used. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: i386 sh sh64 ready for split ptlockHugh Dickins
Use pte_offset_map_lock, instead of pte_offset_map (or inappropriate pte_offset_kernel) and mm-wide page_table_lock, in sundry arch places. The i386 vm86 mark_screen_rdonly: yes, there was and is an assumption that the screen fits inside the one page table, as indeed it does. The sh __do_page_fault: which handles both kernel faults (without lock) and user mm faults (locked - though it set_pte without locking before). The sh64 flush_cache_range and helpers: which wrongly thought callers held page_table_lock before (only its tlb_start_vma did, and no longer does so); moved the flush loop down, and adjusted the large versus small range decision to consider a range which spans page tables as large. Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: kill check_user_page_readableHugh Dickins
check_user_page_readable is a problematic variant of follow_page. It's used only by oprofile's i386 and arm backtrace code, at interrupt time, to establish whether a userspace stackframe is currently readable. This is problematic, because we want to push the page_table_lock down inside follow_page, and later split it; whereas oprofile is doing a spin_trylock on it (in the i386 case, forgotten in the arm case), and needs that to pin perhaps two pages spanned by the stackframe (which might be covered by different locks when we split). I think oprofile is going about this in the wrong way: it doesn't need to know the area is readable (neither i386 nor arm uses read protection of user pages), it doesn't need to pin the memory, it should simply __copy_from_user_inatomic, and see if that succeeds or not. Sorry, but I've not got around to devising the sparse __user annotations for this. Then we can eliminate check_user_page_readable, and return to a single follow_page without the __follow_page variants. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: flush_tlb_range outside ptlockHugh Dickins
There was one small but very significant change in the previous patch: mprotect's flush_tlb_range fell outside the page_table_lock: as it is in 2.4, but that doesn't prove it safe in 2.6. On some architectures flush_tlb_range comes to the same as flush_tlb_mm, which has always been called from outside page_table_lock in dup_mmap, and is so proved safe. Others required a deeper audit: I could find no reliance on page_table_lock in any; but in ia64 and parisc found some code which looks a bit as if it might want preemption disabled. That won't do any actual harm, so pending a decision from the maintainers, disable preemption there. Remove comments on page_table_lock from flush_tlb_mm, flush_tlb_range and flush_tlb_page entries in cachetlb.txt: they were rather misleading (what generic code does is different from what usually happens), the rules are now changing, and it's not yet clear where we'll end up (will the generic tlb_flush_mmu happen always under lock? never under lock? or sometimes under and sometimes not?). Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: arches skip ptlockHugh Dickins
Convert those few architectures which are calling pud_alloc, pmd_alloc, pte_alloc_map on a user mm, not to take the page_table_lock first, nor drop it after. Each of these can continue to use pte_alloc_map, no need to change over to pte_alloc_map_lock, they're neither racy nor swappable. In the sparc64 io_remap_pfn_range, flush_tlb_range then falls outside of the page_table_lock: that's okay, on sparc64 it's like flush_tlb_mm, and that has always been called from outside of page_table_lock in dup_mmap. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: init_mm without ptlockHugh Dickins
First step in pushing down the page_table_lock. init_mm.page_table_lock has been used throughout the architectures (usually for ioremap): not to serialize kernel address space allocation (that's usually vmlist_lock), but because pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it. Reverse that: don't lock or unlock init_mm.page_table_lock in any of the architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take and drop it when allocating a new one, to check lest a racing task already did. Similarly no page_table_lock in vmalloc's map_vm_area. Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle user mms, which are converted only by a later patch, for now they have to lock differently according to whether or not it's init_mm. If sources get muddled, there's a danger that an arch source taking init_mm.page_table_lock will be mixed with common source also taking it (or neither take it). So break the rules and make another change, which should break the build for such a mismatch: remove the redundant mm arg from pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13). Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64 used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64 map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free took page_table_lock for no good reason. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: ia64 use expand_upwardsHugh Dickins
ia64 has expand_backing_store function for growing its Register Backing Store vma upwards. But more complete code for this purpose is found in the CONFIG_STACK_GROWSUP part of mm/mmap.c. Uglify its #ifdefs further to provide expand_upwards for ia64 as well as expand_stack for parisc. The Register Backing Store vma should be marked VM_ACCOUNT. Implement the intention of growing it only a page at a time, instead of passing an address outside of the vma to handle_mm_fault, with unknown consequences. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] core remove PageReservedNick Piggin
Remove PageReserved() calls from core code by tightening VM_RESERVED handling in mm/ to cover PageReserved functionality. PageReserved special casing is removed from get_page and put_page. All setting and clearing of PageReserved is retained, and it is now flagged in the page_alloc checks to help ensure we don't introduce any refcount based freeing of Reserved pages. MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being deprecated. We never completely handled it correctly anyway, and is be reintroduced in future if required (Hugh has a proof of concept). Once PageReserved() calls are removed from kernel/power/swsusp.c, and all arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can be trivially removed. Last real user of PageReserved is swsusp, which uses PageReserved to determine whether a struct page points to valid memory or not. This still needs to be addressed (a generic page_is_ram() should work). A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and thus mapcounted and count towards shared rss). These writes to the struct page could cause excessive cacheline bouncing on big systems. There are a number of ways this could be addressed if it is an issue. Signed-off-by: Nick Piggin <npiggin@suse.de> Refcount bug fix for filemap_xip.c Signed-off-by: Carsten Otte <cotte@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29[PATCH] mm: m68k kill stram swapHugh Dickins
Please, please now delete the Atari CONFIG_STRAM_SWAP code. It may be excellent and ingenious code, but its reference to swap_vfsmnt betrays that it hasn't been built since 2.5.1 (four years old come December), it's delving deep into matters which are the preserve of core mm code, its only purpose is to give the more conscientious mm guys an anxiety attack from time to time; yet we keep on breaking it more and more. If you want to use RAM for swap, then if the MTD driver does not already provide just what you need, I'm sure David could be persuaded to add the extra. But you'd also like to be able to allocate extents of that swap for other use: we can give you a core interface for that if you need. But unbuilt for four years suggests to me that there's no need at all. I cannot swear the patch below won't break your build, but believe so. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>