Since taking a spinlock disables preempt, and we need to spinlock tlb flush
on SMP for N class, we might as well just spinlock on uniprocessor machines
too.
Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
We actually have two separate bad bugs
1. The read_lock implementation spins with disabled interrupts. This is
completely wrong
2. Our spin_lock_irqsave should check to see if interrupts were enabled
before the call and re-enable interrupts around the inner spin loop.
The problem is that if we spin with interrupts off, we can't receive
IPIs. This has resulted in a bug where SMP machines suddenly spit
smp_call_function timeout messages and hang.
The scenario I've caught is
CPU0 does a flush_tlb_all holding the vmlist_lock for write.
CPU1 tries a cat of /proc/meminfo which tries to acquire vmlist_lock for
read
CPU1 is now spinning with interrupts disabled
CPU0 tries to execute a smp_call_function to flush the local tlb caches
This is now a deadlock because CPU1 is spinning with interrupts disabled
and can never receive the IPI
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
This really only adds them for the machines I can check SMP on, which
is CPU interrupts and IOSAPIC (so not any of the GSC based machines).
With this patch, irqbalanced can be used to maintain irq balancing.
Unfortunately, irqbalanced is a bit x86 centric, so it doesn't do an
incredibly good job, but it does work.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Since irq.c uses smp_send_all_nop, we must define it for UP builds
as well. Make it a static inline so it gets optimized away. This forces
irq.c to include <asm/smp.h> though.
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Fix our interrupts not to use smp_call_function
On K and D class smp, the generic code calls this under an irq
spinlock, which causes the WARN_ON() message in smp_call_function()
(and is also illegal because it could deadlock).
The fix is to use a new scheme based on the IPI_NOP.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Introduce an atomic_inc_not_zero operation. Make this a special case of
atomic_add_unless because lockless pagecache actually wants
atomic_inc_not_negativeone due to its offset refcount.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix more include file problems that surfaced since I submitted the previous
fix-missing-includes.patch. This should now allow not to include sched.h
from module.h, which is done by a followup patch.
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
__MUTEX_INITIALIZER() has no users, and equates to the more commonly used
DECLARE_MUTEX(), thus making it pretty much redundant. Remove it for good.
Signed-off-by: Arthur Othieno <a.othieno@bluewin.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make the pid argument a long as on every other arcihtecture. Despite pid_t
beeing a 32bit type even on 64bit parisc this is not an ABI change due to
the parisc calling conventions. And even if it did it wouldn't matter too
much because 64bit userspace on parisc is in an embrionic stage.
Acked-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Removed some more references to check_region().
I checked these changes into the 'checkreg' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
The only valid references remaining are in:
drivers/scsi/advansys.c
drivers/scsi/BusLogic.c
drivers/cdrom/sbpcd.c
sound/oss/pss.c
Remove last vestiges of ide_check_region()
drivers/char/specialix: trim trailing whitespace
drivers/char/specialix: eliminate use of check_region()
Remove outdated and unused references to check_region()
[sound oss] remove check_region() usage from cs4232, wavfront
[netdrvr eepro] trim trailing whitespace
[netdrvr eepro] remove check_region() usage
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The following series implements memory hot-add for ppc64 and i386. There are
x86_64 and ia64 implementations that will be submitted shortly as well,
through the normal maintainers.
This patch:
local_mapnr is unused, except for in an alpha header. Keep the alpha one,
kill the rest.
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>
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>
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>
fixup.S needs to specify .level and use correct LDREG macro.
New binutils has a bug where it doesn't "promote" from PA1.0 to PA1.1
correctly when using ",s" completer.
remove use of __LP64__ in assembly.h and add some white space.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
drivers/infiniband depends on definition of pgprot_noncached() macro.
Someone else will have to fix it's wrong.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Fix the alloc_slabmgmt panic
Hopefully this should also fix a lot of other intermittent kernel bugs.
The problem has been around since 2.6.9-rc2-pa6 when we allowed
floating point registers to be used in kernel code. The essence of
the problem is that gcc prefers to use floating point for integer
divides and multiples. Further, it can rely on the values in the no
clobber fp regs being correct across a function call. Unfortunately,
our task switch function only saves the integer no clobber registers,
not the fp ones, so if gcc makes a function call to any function in
the kernel which could sleep, the values it is relying on in any no
clobber floating point register may be lost. In the case of
alloc_slabmgmt, the value of the page offset is being stored in %fr12
across a call to kmem_getpages(), which sleeps if no pages are
available. Thus, the offset can be trashed and the slab code can end
up with a completely bogus address leading to corruption.
Kudos to Randolph who came up with the program to trip this problem at
will and thus allowed it to be tracked and fixed.
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2.6.12-rc1-pa6 use work queue in LED/LCD driver instead of tasklet.
Main advantage is it allows use of msleep() in the led_LCD_driver to
"atomically" perform two MMIO writes (CMD, then DATA).
Lead to nice cleanup of the main led_work_func() and led_LCD_driver().
Kudos to David for being persistent.
From: David Pye <dmp@davidmpye.dyndns.org>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Optimize ext2_find_next_zero_bit. Gives about 25% perf improvement with a
rsync test with ext3.
Signed-off-by: Randolph Chung <tausq@parisc-linux.org>
fix ext3 performance - ext2_find_next_zero() was culprit.
Kudos to jejb for pointing out the the possibility that ext2_test_bit
and ext2_find_next_zero() may in fact not be enumerating bits in
the bitmap because of endianess. Took sparc64 implementation and
adapted it to our tree. I suspect the real problem is ffz() wants
an unsigned long and was getting garbage in the top half of the
unsigned int. Not confirmed but that's what I suspect.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Fix find_next_bit for 32-bit
Make masking consistent for bitops
From: Joel Soete <soete.joel@tiscali.be>
Signed-off-by: Randolph Chung <tausq@parisc-linux.org>
Add back incorrectly removed ext2_find_first_zero_bit definition
Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Fixup bitops.h to use volatile for *_bit() ops
Based on this email thread:
http://marc.theaimsgroup.com/?t=108826637900003
In a nutshell:
*_bit() want use of volatile.
__*_bit() are "relaxed" and don't use spinlock or volatile.
other minor changes:
o replaces hweight64() macro with alias to generic_hweight64() (Joel Soete)
o cleanup ext2* macros so (a) it's obvious what the XOR magic is about
and (b) one version that works for both 32/64-bit.
o replace 2 uses of CONFIG_64BIT with __LP64__. bitops.h used both.
I think header files that might go to user space should use
something userspace will know about (__LP64__).
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Move SHIFT_PER_LONG to standard location for BITS_PER_LONG (asm/types.h)
and ditch the second definition of BITS_PER_LONG in bitops.h
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
