1. 11 Aug, 2008 40 commits
    • Linus Torvalds's avatar
      Merge branch 'core-fixes-for-linus' of... · 9b4d0bab
      Linus Torvalds authored
      Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        lockdep: fix debug_lock_alloc
        lockdep: increase MAX_LOCKDEP_KEYS
        generic-ipi: fix stack and rcu interaction bug in smp_call_function_mask()
        lockdep: fix overflow in the hlock shrinkage code
        lockdep: rename map_[acquire|release]() => lock_map_[acquire|release]()
        lockdep: handle chains involving classes defined in modules
        mm: fix mm_take_all_locks() locking order
        lockdep: annotate mm_take_all_locks()
        lockdep: spin_lock_nest_lock()
        lockdep: lock protection locks
        lockdep: map_acquire
        lockdep: shrink held_lock structure
        lockdep: re-annotate scheduler runqueues
        lockdep: lock_set_subclass - reset a held lock's subclass
        lockdep: change scheduler annotation
        debug_locks: set oops_in_progress if we will log messages.
        lockdep: fix combinatorial explosion in lock subgraph traversal
      9b4d0bab
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · 7019b1b5
      Linus Torvalds authored
      Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        x86: fix 2.6.27rc1 cannot boot more than 8CPUs
        x86: make "apic" an early_param() on 32-bit, NULL check
        EFI, x86: fix function prototype
        x86, pci-calgary: fix function declaration
        x86: work around gcc 3.4.x bug
        x86: make "apic" an early_param() on 32-bit
        x86, debug: tone down arch/x86/kernel/mpparse.c debugging printk
        x86_64: restore the proper NR_IRQS define so larger systems work.
        x86: Restore proper vector locking during cpu hotplug
        x86: Fix broken VMI in 2.6.27-rc..
        x86: fdiv bug detection fix
      7019b1b5
    • Ingo Molnar's avatar
      Merge branch 'core/locking' into core/urgent · 23a0ee90
      Ingo Molnar authored
      23a0ee90
    • Peter Zijlstra's avatar
      lockdep: fix debug_lock_alloc · 0f2bc27b
      Peter Zijlstra authored
      When we enable DEBUG_LOCK_ALLOC but do not enable PROVE_LOCKING and or
      LOCK_STAT, lock_alloc() and lock_release() turn into nops, even though
      we should be doing hlock checking (check=1).
      
      This causes a false warning and a lockdep self-disable.
      
      Rectify this.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0f2bc27b
    • Yinghai Lu's avatar
      x86: fix 2.6.27rc1 cannot boot more than 8CPUs · b74548e7
      Yinghai Lu authored
      Jeff Chua reported that booting a !bigsmp kernel on a 16-way box
      hangs silently.
      
      this is a long-standing issue, smp start AP cpu could check the
      apic id >=8 etc before trying to start it.
      
      achieve this by moving the def_to_bigsmp check later and skip the
      apicid id > 8
      
      [ mingo@elte.hu: clean up the message that is printed. ]
      Reported-by: default avatar"Jeff Chua" <jeff.chua.linux@gmail.com>
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      
       arch/x86/kernel/setup.c   |    6 ------
       arch/x86/kernel/smpboot.c |   10 ++++++++++
       2 files changed, 10 insertions(+), 6 deletions(-)
      b74548e7
    • Adrian Bunk's avatar
      make struct scsi_dh_devlist's static · f08c0761
      Adrian Bunk authored
      This patch makes several needlessly global struct scsi_dh_devlist's
      static.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f08c0761
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.o-hand.com/linux-mfd · 10fec20e
      Linus Torvalds authored
      * 'for-linus' of git://git.o-hand.com/linux-mfd:
        mfd: tc6393 cleanup and update
        mfd: have TMIO drivers and subdevices depend on ARM
        mfd: TMIO MMC driver
        mfd: driver for the TMIO NAND controller
        mfd: t7l66 MMC platform data
        mfd: tc6387 MMC platform data
        mfd: Fix 7l66 and 6387 according to the new mfd-core API
        mfd: Fix tc6393 according to the new tmio.h
        mfd: driver for the TC6387XB TMIO controller.
        mfd: driver for the T7L66XB TMIO SoC
        mfd: TMIO MMC structures and accessors.
      10fec20e
    • Linus Torvalds's avatar
      Merge branch 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6 · 29bb1bdb
      Linus Torvalds authored
      * 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
        hwmon: (lm75) Drop legacy i2c driver
        i2c: correct some size_t printk formats
        i2c: Check for address business before creating clients
        i2c: Let users select algorithm drivers manually again
        i2c: Fix NULL pointer dereference in i2c_new_probed_device
        i2c: Fix oops on bus multiplexer driver loading
      29bb1bdb
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog · 3f1ae223
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
        [WATCHDOG] pcwd.c - fix open_allowed type.
        [WATCHDOG] fix watchdog/ixp4xx_wdt.c compilation
        [WATCHDOG] fix watchdog/wdt285.c compilation
        [WATCHDOG] fix watchdog/at91rm9200_wdt.c compilation
        [WATCHDOG] fix watchdog/shwdt.c compilation
        [WATCHDOG] fix watchdog/txx9wdt.c compilation
        [WATCHDOG] MAINTAINERS: remove ZF MACHZ WATCHDOG entry
        [WATCHDOG] Fix build with CONFIG_ITCO_VENDOR_SUPPORT=n
      3f1ae223
    • Rene Herman's avatar
      x86: make "apic" an early_param() on 32-bit, NULL check · 48d97cb6
      Rene Herman authored
      Cyrill Gorcunov observed:
      
      > you turned it into early_param so now it's NULL injecting vulnerabled.
      > Could you please add checking for NULL str param?
      
      fix that.
      
      Also, change the name of 'str' into 'arg', to make it more apparent
      that this is an optional argument that can be NULL, not a string
      parameter that is empty when unset.
      Reported-by: default avatarCyrill Gorcunov <gorcunov@gmail.com>
      Signed-off-by: default avatarRene Herman <rene.herman@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      48d97cb6
    • Linus Torvalds's avatar
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc · e2205a15
      Linus Torvalds authored
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
        powerpc: Remove include/linux/harrier_defs.h
        powerpc: Do not ignore arch/powerpc/include
        powerpc: Delete completed "ppc removal" task from feature removal file
        powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
        powerpc/pci: Don't keep ISA memory hole resources in the tree
        powerpc: Zero fill the return values of rtas argument buffer
        powerpc/4xx: Update defconfig files for 2.6.27-rc1
        powerpc/44x: Incorrect NOR offset in Warp DTS
        powerpc/44x: Warp DTS changes for board updates
        powerpc/4xx: Cleanup Warp for i2c driver changes.
        powerpc/44x: Adjust warp-nand resource end address
      e2205a15
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 · a7ef6a40
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
        PCI: Limit VPD length for Broadcom 5708S
        PCI PM: Export pci_pme_active to drivers
        PCI: remove duplicate symbol from pci_ids.h
        PCI: check the return value of device_create_bin_file() in pci_create_bus()
        PCI: fully restore MSI state at resume time
        DMA: make dma-coherent.c documentation kdoc-friendly
        PCI: make pci_register_driver() a macro
        PCI: add Broadcom 5708S to VPD length quirk
      a7ef6a40
    • Christian Borntraeger's avatar
      Fix race/oops in tty layer after BKL pushdown · 000b9151
      Christian Borntraeger authored
      While testing our KVM code for s390 (starting and killall kvm in a loop)
      I can reproduce the following oops:
      
        Unable to handle kernel pointer dereference at virtual kernel address 6b6b6b6b6b6b6000 Oops: 0038 [#1] SMP
        Modules linked in: dm_multipath sunrpc qeth_l3 qeth_l2 dm_mod qeth
        ccwgroup CPU: 1 Not tainted 2.6.27-rc1 #54
        Process kuli (pid: 4409, task: 00000000b6aa5940, ksp: 00000000b7343e10)
        Krnl PSW : 0704e00180000000 00000000002e0b8c
        (disassociate_ctty+0x1c0/0x288) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3
        CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000000 6b6b6b6b6b6b6b6b
        0000000000000001 00000000000003a6 00000000002e0a46 00000000004b4160
        0000000000000001 00000000bbd79758 00000000b7343e58 00000000b8854148
        00000000bd34dea0 00000000b7343c20 0000000000000001 00000000004b6d08
        00000000002e0a46 00000000b7343c20 Krnl Code: 00000000002e0b7e:
        eb9fb0a00004	lmg	%r9,%r15,160(%r11) 00000000002e0b84:
        07f4		bcr	15,%r4 00000000002e0b86:
        e31090080004	lg	%r1,8(%r9) >00000000002e0b8c:
        d501109cd000	clc	156(2,%r1),0(%r13) 00000000002e0b92:
        a784ff5d		brc	8,2e0a4c 00000000002e0b96:
        b9040029		lgr	%r2,%r9 00000000002e0b9a:
        c0e5fffff9c3	brasl	%r14,2dff20 00000000002e0ba0:
        a7f4ff56		brc	15,2e0a4c Call Trace:
        ([<00000000002e0a46>] disassociate_ctty+0x7a/0x288)
         [<0000000000141fe6>] do_exit+0x212/0x8d4
         [<0000000000142708>] do_group_exit+0x60/0xcc
         [<0000000000150660>] get_signal_to_deliver+0x270/0x3ac
         [<000000000010bfd6>] do_signal+0x8e/0x8dc
         [<0000000000113772>] sysc_sigpending+0xe/0x22
         [<000001ff0000b134>] 0x1ff0000b134
        INFO: lockdep is turned off.
        Last Breaking-Event-Address:
         [<00000000002e0a48>] disassociate_ctty+0x7c/0x288
        Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      It seems that tty was already free in disassocate_ctty when it tries
      to dereference tty->driver.
      
      After moving the lock_kernel before the mutex_unlock, I can no longer
      reproduce the problem.
      
      [ This is a temporary partial fix for the documented and long standing
        race in disassociate_tty.  This stops most problem cases for now.
      
        For the next release the -next tree has an initial implementation of
        kref counting for tty structures and this quickfix will be dropped.
      
                                                                    - Alan ]
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by; Alan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      000b9151
    • Geert Uytterhoeven's avatar
      m68k{,nommu}: Wire up new system calls · 0e7d5bb8
      Geert Uytterhoeven authored
      Wire up for m68k{,nommu} the system calls that were added in the last merge
      window:
      
       - 4006553b ("flag parameters: inotify_init")
       - ed8cae8b ("flag parameters: pipe")
       - 336dd1f7 ("flag parameters: dup2")
       - a0998b50 ("flag parameters: epoll_create")
       - 9fe5ad9c ("flag parameters add-on: remove
      						 epoll_create size param")
       - b087498e ("flag parameters: eventfd")
       - 9deb27ba ("flag parameters: signalfd")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0e7d5bb8
    • Linus Torvalds's avatar
      Revert "fbcon: bgcolor fix" · 3838f59f
      Linus Torvalds authored
      This reverts commit 2d04a4a7, which made
      it impossible to make the softcursor use the highlight colors.
      
      Yes, the fourth bit should be "blinking", but since we cannot reasonably
      blink in fbcon, highlighting it with a bright background is preferable.
      Reported-by: default avatarPavel Machek <pavel@suse.cz>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: Antonino A. Daplas <adaplas@pol.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3838f59f
    • Randy Dunlap's avatar
      EFI, x86: fix function prototype · b0fbaa6b
      Randy Dunlap authored
      Fix function prototype in header file to match source code:
      
      linux-next-20080807/arch/x86/kernel/efi_64.c:100:14: error: symbol 'efi_ioremap' redeclared with different type (originally declared at include2/asm/efi.h:89) - different address spaces
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b0fbaa6b
    • Randy Dunlap's avatar
      x86, pci-calgary: fix function declaration · 9b0094f7
      Randy Dunlap authored
      Fix function declaration:
      
       linux-next-20080807/arch/x86/kernel/pci-calgary_64.c:1353:36: warning: non-ANSI function declaration of function 'get_tce_space_from_tar'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: default avatarAcked-by: Muli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9b0094f7
    • Jeremy Fitzhardinge's avatar
      x86: work around gcc 3.4.x bug · cf3e5050
      Jeremy Fitzhardinge authored
      Simon Horman reported that gcc-3.4.x crashes when compiling
      pgd_prepopulate_pmd() when PREALLOCATED_PMDS == 0 and CONFIG_DEBUG_INFO
      is enabled.
      
      Adding an extra check for PREALLOCATED_PMDS == 0 [which is compiled out
      by gcc] seems to avoid the problem.
      Reported-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cf3e5050
    • Rene Herman's avatar
      x86: make "apic" an early_param() on 32-bit · fb6bef80
      Rene Herman authored
      On 32-bit, "apic" is a __setup() param meaning it is parsed rather
      late in the game. Make it an early_param() for apic_printk() use
      by arch/x86/kernel/mpparse.c.
      
      On 64-bit, it already is an early_param().
      Signed-off-by: default avatarRene Herman <rene.herman@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fb6bef80
    • Rene Herman's avatar
      x86, debug: tone down arch/x86/kernel/mpparse.c debugging printk · eeb0d7d1
      Rene Herman authored
      commit 11a62a05 turns some formerly
      nopped debugging printks in arch/x86/kernel/mppparse.c into regular
      ones. The one at the top of smp_scan_config() in particular also
      prints on !CONFIG_SMP/CONFIG_X86_LOCAL_APIC kernels and UP machines
      without anything resembling MP tables which makes their lowly UP
      owners wonder...
      
      Turn the former Dprintk()s into apic_printk()s instead meaning that
      their printing is dependent on passing the apic=verbose (or =debug)
      command line param.
      
      On 32-bit, "apic" is a __setup() param which isn't early enough
      for this code and therefore needs a followup changing it into an
      early_param(). On 64-bit, it already is.
      Signed-off-by: default avatarRene Herman <rene.herman@gmail.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      eeb0d7d1
    • Ingo Molnar's avatar
      lockdep: increase MAX_LOCKDEP_KEYS · e5f363e3
      Ingo Molnar authored
      certain configs produce:
      
       [   70.076229] BUG: MAX_LOCKDEP_KEYS too low!
       [   70.080230] turning off the locking correctness validator.
      
      tune them up.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e5f363e3
    • Nick Piggin's avatar
      generic-ipi: fix stack and rcu interaction bug in smp_call_function_mask() · cc7a486c
      Nick Piggin authored
      * Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote:
      
      > Found a OOPS on a big SMP box during an overnight reboot test with
      > upstream git.
      >
      > Suresh and I looked at the oops and looks like the root cause is in
      > generic_smp_call_function_interrupt() and smp_call_function_mask() with
      > wait parameter.
      >
      > The actual oops looked like
      >
      > [   11.277260] BUG: unable to handle kernel paging request at ffff8802ffffffff
      > [   11.277815] IP: [<ffff8802ffffffff>] 0xffff8802ffffffff
      > [   11.278155] PGD 202063 PUD 0
      > [   11.278576] Oops: 0010 [1] SMP
      > [   11.279006] CPU 5
      > [   11.279336] Modules linked in:
      > [   11.279752] Pid: 0, comm: swapper Not tainted 2.6.27-rc2-00020-g685d87f7 #290
      > [   11.280039] RIP: 0010:[<ffff8802ffffffff>]  [<ffff8802ffffffff>] 0xffff8802ffffffff
      > [   11.280692] RSP: 0018:ffff88027f1f7f70  EFLAGS: 00010086
      > [   11.280976] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000
      > [   11.281264] RDX: 0000000000004f4e RSI: 0000000000000001 RDI: 0000000000000000
      > [   11.281624] RBP: ffff88027f1f7f98 R08: 0000000000000001 R09: ffffffff802509af
      > [   11.281925] R10: ffff8800280c2780 R11: 0000000000000000 R12: ffff88027f097d48
      > [   11.282214] R13: ffff88027f097d70 R14: 0000000000000005 R15: ffff88027e571000
      > [   11.282502] FS:  0000000000000000(0000) GS:ffff88027f1c3340(0000) knlGS:0000000000000000
      > [   11.283096] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      > [   11.283382] CR2: ffff8802ffffffff CR3: 0000000000201000 CR4: 00000000000006e0
      > [   11.283760] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   11.284048] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > [   11.284337] Process swapper (pid: 0, threadinfo ffff88027f1f2000, task ffff88027f1f0640)
      > [   11.284936] Stack:  ffffffff80250963 0000000000000212 0000000000ee8c78 0000000000ee8a66
      > [   11.285802]  ffff88027e571550 ffff88027f1f7fa8 ffffffff8021adb5 ffff88027f1f3e40
      > [   11.286599]  ffffffff8020bdd6 ffff88027f1f3e40 <EOI>  ffff88027f1f3ef8 0000000000000000
      > [   11.287120] Call Trace:
      > [   11.287768]  <IRQ>  [<ffffffff80250963>] ? generic_smp_call_function_interrupt+0x61/0x12c
      > [   11.288354]  [<ffffffff8021adb5>] smp_call_function_interrupt+0x17/0x27
      > [   11.288744]  [<ffffffff8020bdd6>] call_function_interrupt+0x66/0x70
      > [   11.289030]  <EOI>  [<ffffffff8024ab3b>] ? clockevents_notify+0x19/0x73
      > [   11.289380]  [<ffffffff803b9b75>] ? acpi_idle_enter_simple+0x18b/0x1fa
      > [   11.289760]  [<ffffffff803b9b6b>] ? acpi_idle_enter_simple+0x181/0x1fa
      > [   11.290051]  [<ffffffff8053aeca>] ? cpuidle_idle_call+0x70/0xa2
      > [   11.290338]  [<ffffffff80209f61>] ? cpu_idle+0x5f/0x7d
      > [   11.290723]  [<ffffffff8060224a>] ? start_secondary+0x14d/0x152
      > [   11.291010]
      > [   11.291287]
      > [   11.291654] Code:  Bad RIP value.
      > [   11.292041] RIP  [<ffff8802ffffffff>] 0xffff8802ffffffff
      > [   11.292380]  RSP <ffff88027f1f7f70>
      > [   11.292741] CR2: ffff8802ffffffff
      > [   11.310951] ---[ end trace 137c54d525305f1c ]---
      >
      > The problem is with the following sequence of events:
      >
      > - CPU A calls smp_call_function_mask() for CPU B with wait parameter
      > - CPU A sets up the call_function_data on the stack and does an rcu add to
      >   call_function_queue
      > - CPU A waits until the WAIT flag is cleared
      > - CPU B gets the call function interrupt and starts going through the
      >   call_function_queue
      > - CPU C also gets some other call function interrupt and starts going through
      >   the call_function_queue
      > - CPU C, which is also going through the call_function_queue, starts referencing
      >   CPU A's stack, as that element is still in call_function_queue
      > - CPU B finishes the function call that CPU A set up and as there are no other
      >   references to it, rcu deletes the call_function_data (which was from CPU A
      >   stack)
      > - CPU B sees the wait flag and just clears the flag (no call_rcu to free)
      > - CPU A which was waiting on the flag continues executing and the stack
      >   contents change
      >
      > - CPU C is still in rcu_read section accessing the CPU A's stack sees
      >   inconsistent call_funation_data and can try to execute
      >   function with some random pointer, causing stack corruption for A
      >   (by clearing the bits in mask field) and oops.
      
      Nice debugging work.
      
      I'd suggest something like the attached (boot tested) patch as the simple
      fix for now.
      
      I expect the benefits from the less synchronized, multiple-in-flight-data
      global queue will still outweigh the costs of dynamic allocations. But
      if worst comes to worst then we just go back to a globally synchronous
      one-at-a-time implementation, but that would be pretty sad!
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cc7a486c
    • Paul Mackerras's avatar
      powerpc: Remove include/linux/harrier_defs.h · 13fa00a8
      Paul Mackerras authored
      It was only used by code in arch/ppc, and arch/ppc is gone, so remove
      the unused harrier_defs.h as well.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      13fa00a8
    • Peter Zijlstra's avatar
      lockdep: fix overflow in the hlock shrinkage code · b42e737e
      Peter Zijlstra authored
      There is a overflow by 1 case in the new shrunken hlock code.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b42e737e
    • Eric W. Biederman's avatar
      x86_64: restore the proper NR_IRQS define so larger systems work. · 3c7569b2
      Eric W. Biederman authored
      As pointed out and tracked by Yinghai Lu <yhlu.kernel@gmail.com>:
      
       Dhaval Giani got:
       kernel BUG at arch/x86/kernel/io_apic_64.c:357!
       invalid opcode: 0000 [1] SMP
       CPU 24
       ...
      
      his system (x3950) has 8 ioapic, irq > 256
      
      This was caused by:
      
             commit 9b7dc567
             Author: Thomas Gleixner <tglx@linutronix.de>
             Date:   Fri May 2 20:10:09 2008 +0200
      
                x86: unify interrupt vector defines
      
                The interrupt vector defines are copied 4 times around with minimal
                differences. Move them all into asm-x86/irq_vectors.h
      
      It appears that Thomas did not notice that x86_64 does something
      completely different when he merge irq_vectors.h
      
      We can solve this for 2.6.27 by simply reintroducing the old heuristic
      for setting NR_IRQS on x86_64 to a usable value, which trivially removes
      the regression.
      
      Long term it would be nice to harmonize the handling of ioapic interrupts
      of x86_32 and x86_64 so we don't have this kind of confusion.
      
      Dhaval Giani <dhaval@linux.vnet.ibm.com> tested an earlier version of
      this patch by YH which confirms simply increasing NR_IRQS fixes the
      problem.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Acked-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3c7569b2
    • Eric W. Biederman's avatar
      x86: Restore proper vector locking during cpu hotplug · d388e5fd
      Eric W. Biederman authored
      Having cpu_online_map change during assign_irq_vector can result
      in some really nasty and weird things happening.  The one that
      bit me last time was accessing non existent per cpu memory for non
      existent cpus.
      
      This locking was removed in a sloppy x86_64 and x86_32 merge patch.
      
      Guys can we please try and avoid subtly breaking x86 when we are
      merging files together?
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      d388e5fd
    • Ingo Molnar's avatar
      lockdep: rename map_[acquire|release]() => lock_map_[acquire|release]() · 3295f0ef
      Ingo Molnar authored
      the names were too generic:
      
       drivers/uio/uio.c:87: error: expected identifier or '(' before 'do'
       drivers/uio/uio.c:87: error: expected identifier or '(' before 'while'
       drivers/uio/uio.c:113: error: 'map_release' undeclared here (not in a function)
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3295f0ef
    • Rabin Vincent's avatar
      lockdep: handle chains involving classes defined in modules · 8bfe0298
      Rabin Vincent authored
      Solve this by marking the classes as unused and not printing information
      about the unused classes.
      Reported-by: default avatarEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Acked-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8bfe0298
    • Peter Zijlstra's avatar
      mm: fix mm_take_all_locks() locking order · 7cd5a02f
      Peter Zijlstra authored
      Lockdep spotted:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.27-rc1 #270
      -------------------------------------------------------
      qemu-kvm/2033 is trying to acquire lock:
       (&inode->i_data.i_mmap_lock){----}, at: [<ffffffff802996cc>] mm_take_all_locks+0xc2/0xea
      
      but task is already holding lock:
       (&anon_vma->lock){----}, at: [<ffffffff8029967a>] mm_take_all_locks+0x70/0xea
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&anon_vma->lock){----}:
             [<ffffffff8025cd37>] __lock_acquire+0x11be/0x14d2
             [<ffffffff8025d0a9>] lock_acquire+0x5e/0x7a
             [<ffffffff804c655b>] _spin_lock+0x3b/0x47
             [<ffffffff8029a2ef>] vma_adjust+0x200/0x444
             [<ffffffff8029a662>] split_vma+0x12f/0x146
             [<ffffffff8029bc60>] mprotect_fixup+0x13c/0x536
             [<ffffffff8029c203>] sys_mprotect+0x1a9/0x21e
             [<ffffffff8020c0db>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #0 (&inode->i_data.i_mmap_lock){----}:
             [<ffffffff8025ca54>] __lock_acquire+0xedb/0x14d2
             [<ffffffff8025d397>] lock_release_non_nested+0x1c2/0x219
             [<ffffffff8025d515>] lock_release+0x127/0x14a
             [<ffffffff804c6403>] _spin_unlock+0x1e/0x50
             [<ffffffff802995d9>] mm_drop_all_locks+0x7f/0xb0
             [<ffffffff802a965d>] do_mmu_notifier_register+0xe2/0x112
             [<ffffffff802a96a8>] mmu_notifier_register+0xe/0x10
             [<ffffffffa0043b6b>] kvm_dev_ioctl+0x11e/0x287 [kvm]
             [<ffffffff802bd0ca>] vfs_ioctl+0x2a/0x78
             [<ffffffff802bd36f>] do_vfs_ioctl+0x257/0x274
             [<ffffffff802bd3e1>] sys_ioctl+0x55/0x78
             [<ffffffff8020c0db>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      other info that might help us debug this:
      
      5 locks held by qemu-kvm/2033:
       #0:  (&mm->mmap_sem){----}, at: [<ffffffff802a95d0>] do_mmu_notifier_register+0x55/0x112
       #1:  (mm_all_locks_mutex){--..}, at: [<ffffffff8029963e>] mm_take_all_locks+0x34/0xea
       #2:  (&anon_vma->lock){----}, at: [<ffffffff8029967a>] mm_take_all_locks+0x70/0xea
       #3:  (&anon_vma->lock){----}, at: [<ffffffff8029967a>] mm_take_all_locks+0x70/0xea
       #4:  (&anon_vma->lock){----}, at: [<ffffffff8029967a>] mm_take_all_locks+0x70/0xea
      
      stack backtrace:
      Pid: 2033, comm: qemu-kvm Not tainted 2.6.27-rc1 #270
      
      Call Trace:
       [<ffffffff8025b7c7>] print_circular_bug_tail+0xb8/0xc3
       [<ffffffff8025ca54>] __lock_acquire+0xedb/0x14d2
       [<ffffffff80259bb1>] ? add_lock_to_list+0x7e/0xad
       [<ffffffff8029967a>] ? mm_take_all_locks+0x70/0xea
       [<ffffffff8029967a>] ? mm_take_all_locks+0x70/0xea
       [<ffffffff8025d397>] lock_release_non_nested+0x1c2/0x219
       [<ffffffff802996cc>] ? mm_take_all_locks+0xc2/0xea
       [<ffffffff802996cc>] ? mm_take_all_locks+0xc2/0xea
       [<ffffffff8025b202>] ? trace_hardirqs_on_caller+0x4d/0x115
       [<ffffffff802995d9>] ? mm_drop_all_locks+0x7f/0xb0
       [<ffffffff8025d515>] lock_release+0x127/0x14a
       [<ffffffff804c6403>] _spin_unlock+0x1e/0x50
       [<ffffffff802995d9>] mm_drop_all_locks+0x7f/0xb0
       [<ffffffff802a965d>] do_mmu_notifier_register+0xe2/0x112
       [<ffffffff802a96a8>] mmu_notifier_register+0xe/0x10
       [<ffffffffa0043b6b>] kvm_dev_ioctl+0x11e/0x287 [kvm]
       [<ffffffff8033f9f2>] ? file_has_perm+0x83/0x8e
       [<ffffffff802bd0ca>] vfs_ioctl+0x2a/0x78
       [<ffffffff802bd36f>] do_vfs_ioctl+0x257/0x274
       [<ffffffff802bd3e1>] sys_ioctl+0x55/0x78
       [<ffffffff8020c0db>] system_call_fastpath+0x16/0x1b
      
      Which the locking hierarchy in mm/rmap.c confirms as valid.
      
      Fix this by first taking all the mapping->i_mmap_lock instances and then
      take all anon_vma->lock instances.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7cd5a02f
    • Peter Zijlstra's avatar
      lockdep: annotate mm_take_all_locks() · 454ed842
      Peter Zijlstra authored
      The nesting is correct due to holding mmap_sem, use the new annotation
      to annotate this.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      454ed842
    • Peter Zijlstra's avatar
      lockdep: spin_lock_nest_lock() · b7d39aff
      Peter Zijlstra authored
      Expose the new lock protection lock.
      
      This can be used to annotate places where we take multiple locks of the
      same class and avoid deadlocks by always taking another (top-level) lock
      first.
      
      NOTE: we're still bound to the MAX_LOCK_DEPTH (48) limit.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b7d39aff
    • Peter Zijlstra's avatar
      lockdep: lock protection locks · 7531e2f3
      Peter Zijlstra authored
      On Fri, 2008-08-01 at 16:26 -0700, Linus Torvalds wrote:
      
      > On Fri, 1 Aug 2008, David Miller wrote:
      > >
      > > Taking more than a few locks of the same class at once is bad
      > > news and it's better to find an alternative method.
      >
      > It's not always wrong.
      >
      > If you can guarantee that anybody that takes more than one lock of a
      > particular class will always take a single top-level lock _first_, then
      > that's all good. You can obviously screw up and take the same lock _twice_
      > (which will deadlock), but at least you cannot get into ABBA situations.
      >
      > So maybe the right thing to do is to just teach lockdep about "lock
      > protection locks". That would have solved the multi-queue issues for
      > networking too - all the actual network drivers would still have taken
      > just their single queue lock, but the one case that needs to take all of
      > them would have taken a separate top-level lock first.
      >
      > Never mind that the multi-queue locks were always taken in the same order:
      > it's never wrong to just have some top-level serialization, and anybody
      > who needs to take <n> locks might as well do <n+1>, because they sure as
      > hell aren't going to be on _any_ fastpaths.
      >
      > So the simplest solution really sounds like just teaching lockdep about
      > that one special case. It's not "nesting" exactly, although it's obviously
      > related to it.
      
      Do as Linus suggested. The lock protection lock is called nest_lock.
      
      Note that we still have the MAX_LOCK_DEPTH (48) limit to consider, so anything
      that spills that it still up shit creek.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7531e2f3
    • Peter Zijlstra's avatar
      lockdep: map_acquire · 4f3e7524
      Peter Zijlstra authored
      Most the free-standing lock_acquire() usages look remarkably similar, sweep
      them into a new helper.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4f3e7524
    • Dave Jones's avatar
      lockdep: shrink held_lock structure · f82b217e
      Dave Jones authored
      struct held_lock {
              u64                        prev_chain_key;       /*     0     8 */
              struct lock_class *        class;                /*     8     8 */
              long unsigned int          acquire_ip;           /*    16     8 */
              struct lockdep_map *       instance;             /*    24     8 */
              int                        irq_context;          /*    32     4 */
              int                        trylock;              /*    36     4 */
              int                        read;                 /*    40     4 */
              int                        check;                /*    44     4 */
              int                        hardirqs_off;         /*    48     4 */
      
              /* size: 56, cachelines: 1 */
              /* padding: 4 */
              /* last cacheline: 56 bytes */
      };
      
      struct held_lock {
              u64                        prev_chain_key;       /*     0     8 */
              long unsigned int          acquire_ip;           /*     8     8 */
              struct lockdep_map *       instance;             /*    16     8 */
              unsigned int               class_idx:11;         /*    24:21  4 */
              unsigned int               irq_context:2;        /*    24:19  4 */
              unsigned int               trylock:1;            /*    24:18  4 */
              unsigned int               read:2;               /*    24:16  4 */
              unsigned int               check:2;              /*    24:14  4 */
              unsigned int               hardirqs_off:1;       /*    24:13  4 */
      
              /* size: 32, cachelines: 1 */
              /* padding: 4 */
              /* bit_padding: 13 bits */
              /* last cacheline: 32 bytes */
      };
      
      [mingo@elte.hu: shrunk hlock->class too]
      [peterz@infradead.org: fixup bit sizes]
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      f82b217e
    • Peter Zijlstra's avatar
      lockdep: re-annotate scheduler runqueues · 1b12bbc7
      Peter Zijlstra authored
      Instead of using a per-rq lock class, use the regular nesting operations.
      
      However, take extra care with double_lock_balance() as it can release the
      already held rq->lock (and therefore change its nesting class).
      
      So what can happen is:
      
       spin_lock(rq->lock);	// this rq subclass 0
      
       double_lock_balance(rq, other_rq);
         // release rq
         // acquire other_rq->lock subclass 0
         // acquire rq->lock subclass 1
      
       spin_unlock(other_rq->lock);
      
      leaving you with rq->lock in subclass 1
      
      So a subsequent double_lock_balance() call can try to nest a subclass 1
      lock while already holding a subclass 1 lock.
      
      Fix this by introducing double_unlock_balance() which releases the other
      rq's lock, but also re-sets the subclass for this rq's lock to 0.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1b12bbc7
    • Peter Zijlstra's avatar
      lockdep: lock_set_subclass - reset a held lock's subclass · 64aa348e
      Peter Zijlstra authored
      this can be used to reset a held lock's subclass, for arbitrary-depth
      iterated data structures such as trees or lists which have per-node
      locks.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      64aa348e
    • Junio C Hamano's avatar
      powerpc: Do not ignore arch/powerpc/include · 0afd2ac9
      Junio C Hamano authored
      Back when .gitignore file was added to arch/powerpc/ in 06f2138e ([POWERPC]
      Add files build to .gitignore, 2006-11-26), there indeed was nothing
      tracked in the ignored hierarchy and ignoring everything made sense.  But
      we have very many tracked files there these days, and having a higher
      level .gitignore that ignores everything is asking for future troubles..
      
      This should have been part of b8b572e1 (powerpc: Move include files to
      arch/powerpc/include/asm, 2008-08-01).
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      Acked-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      0afd2ac9
    • Robert P. J. Day's avatar
    • Benjamin Herrenschmidt's avatar
      powerpc/mm: Fix attribute confusion with htab_bolt_mapping() · bc033b63
      Benjamin Herrenschmidt authored
      The function htab_bolt_mapping() is used to create permanent
      mappings in the MMU hash table, for example, in order to create
      the linear mapping of vmemmap.  It's also used by early boot
      ioremap (before mem_init_done).
      
      However, the way ioremap uses it is incorrect as it passes it the
      protection flags in the "linux PTE" form while htab_bolt_mapping()
      expects them in the hash table format.  This is made more confusing by
      the fact that some of those flags are actually in the same position in
      both cases.
      
      This fixes it all by making htab_bolt_mapping() take normal linux
      protection flags instead, and use a little helper to convert them to
      htab flags. Callers can now use the usual PAGE_* definitions safely.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      
       arch/powerpc/include/asm/mmu-hash64.h |    2 -
       arch/powerpc/mm/hash_utils_64.c       |   65 ++++++++++++++++++++--------------
       arch/powerpc/mm/init_64.c             |    9 +---
       3 files changed, 44 insertions(+), 32 deletions(-)
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      bc033b63
    • Benjamin Herrenschmidt's avatar
      powerpc/pci: Don't keep ISA memory hole resources in the tree · 8db13a0e
      Benjamin Herrenschmidt authored
      When we have an ISA memory hole (ie, a PCI window that allows us to
      generate PCI memory cycles at low PCI address) mixed with other
      resources using a different CPU <=> PCI mapping, we must not keep
      the ISA hole in the bridge resource list.
      
      If we do, things might start trying to allocate device resources
      in there and will get the PCI addresses wrong.
      
      This fixes it by arranging to remove the ISA memory hole resource in
      this case.  This fixes various cases of PCMCIA breakage on PowerBooks
      using the MPC106 "grackle" bridge.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      8db13a0e