1. 22 8月, 2008 1 次提交
  2. 21 8月, 2008 30 次提交
  3. 20 8月, 2008 9 次提交
    • L
      Merge branch 'sh/for-2.6.27' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6 · 1bbe44f6
      Linus Torvalds 提交于
      * 'sh/for-2.6.27' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
        sh: Provide a FLAT_PLAT_INIT() definition.
        binfmt_flat: Stub in a FLAT_PLAT_INIT().
        video: export sh_mobile_lcdc panel size
        sh: select memchunk size using kernel cmdline
        sh: export sh7723 VEU as VEU2H
        input: migor_ts compile and detection fix
        sh: remove MSTPCR defines from Migo-R header file
        sh: Update sh7763rdp defconfig
        sh: Add support sh7760fb to sh7763rdp board
        sh: Add support sh_eth to sh7763rdp board
        sh: Disable 64kB hugetlbpage size when using 64kB PAGE_SIZE.
        sh: Don't export __{s,u}divsi3_i4i from SH-2 libgcc.
        fix SH7705_CACHE_32KB compilation
        sh: mach-x3proto: Fix up smc91x platform data.
      1bbe44f6
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc · 8498ffd6
      Linus Torvalds 提交于
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
        powerpc: Fix vio_bus_probe oops on probe error
        powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices
        powerpc: Fix /dev/oldmem interface for kdump
        powerpc/spufs: Remove invalid semicolon after if statement
        powerpc/spufs: reference context while dropping state mutex in scheduler
        powerpc/spufs: fix npc setting for NOSCHED contexts
      8498ffd6
    • L
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 · c5b0079c
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: (22 commits)
        [SCSI] ibmvfc: Driver version 1.0.2
        [SCSI] ibmvfc: Add details to async event log
        [SCSI] ibmvfc: Sanitize response lengths
        [SCSI] ibmvfc: Fix for lost async events
        [SCSI] ibmvfc: Fixup host state during reinit
        [SCSI] ibmvfc: Fix another hang on module removal
        [SCSI] ibmvscsi: Fixup desired DMA value for shared memory partitions
        [SCSI] megaraid_sas: remove sysfs dbg_lvl world writeable permissions
        [SCSI] qla2xxx: Update version number to 8.02.01-k7.
        [SCSI] qla2xxx: Explicitly tear-down vports during PCI remove_one().
        [SCSI] qla2xxx: Reference proper ha during SBR handling.
        [SCSI] qla2xxx: Set npiv_supported flag for FCoE HBAs.
        [SCSI] qla2xxx: Don't leak SG-DMA mappings while aborting commands.
        [SCSI] qla2xxx: Correct vport-state management issues during ISP-ABORT.
        [SCSI] qla2xxx: Correct synchronization of software/firmware fcport states.
        [SCSI] scsi_dh: Initialize lun_state in check_ownership()
        [SCSI] scsi_dh: Do not use scsilun in rdac hardware handler
        [SCSI] megaraid_sas: version and Documentation Update
        [SCSI] megaraid_sas: add new controllers (0x78 0x79)
        [SCSI] megaraid_sas: add the shutdown DCMD cmd to driver shutdown routine
        ...
      c5b0079c
    • L
      vfat: fix 'sync' mount deadlock due to BKL->lock_super conversion · 5f22ca9b
      Linus Torvalds 提交于
      There was another FAT BKL conversion deadlock reported by Bart
      Trojanowski due to the BKL being used as a recursive lock by FAT, which
      was missed because it only triggers with 'sync' (or 'dirsync') mounts.
      
      The recursion worked for the BKL, but after the conversion to lock_super
      (which uses a mutex), it just deadlocks.
      
      Thanks to Bart for debugging this and testing the fix.  The lock
      debugging information from the original report:
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.27-rc3-bisect-00448-ga7f5aaf3 #16
        ---------------------------------------------
        mv/4020 is trying to acquire lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        but task is already holding lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        other info that might help us debug this:
        3 locks held by mv/4020:
         #0:  (&sb->s_type->i_mutex_key#9/1){--..}, at: [<c01b2336>] do_unlinkat+0x66/0x140
         #1:  (&sb->s_type->i_mutex_key#9){--..}, at: [<c01b0954>] vfs_unlink+0x84/0x110
         #2:  (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        stack backtrace:
        Pid: 4020, comm: mv Not tainted 2.6.27-rc3-bisect-00448-ga7f5aaf3 #16
         [<c014e694>] validate_chain+0x984/0xea0
         [<c0108d70>] ? native_sched_clock+0x0/0xf0
         [<c014ee9c>] __lock_acquire+0x2ec/0x9b0
         [<c014f5cf>] lock_acquire+0x6f/0x90
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c044e5fd>] mutex_lock_nested+0xad/0x300
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] lock_super+0x1e/0x20
         [<f8b3a700>] fat_write_inode+0x60/0x2b0 [fat]
         [<c0450878>] ? _spin_unlock_irqrestore+0x48/0x80
         [<f8b3a953>] ? fat_sync_inode+0x3/0x20 [fat]
         [<f8b3a962>] fat_sync_inode+0x12/0x20 [fat]
         [<f8b37c7e>] fat_remove_entries+0xbe/0x120 [fat]
         [<f8b422ef>] vfat_unlink+0x5f/0x90 [vfat]
         [<f8b42290>] ? vfat_unlink+0x0/0x90 [vfat]
         [<c01b0968>] vfs_unlink+0x98/0x110
         [<c01b2400>] do_unlinkat+0x130/0x140
         [<c016a8f5>] ? audit_syscall_entry+0x105/0x150
         [<c01b253b>] sys_unlinkat+0x3b/0x40
         [<c01040d3>] sysenter_do_call+0x12/0x3f
         =======================
      
      where the deadlock is due to the nesting of lock_super from vfat_unlink
      to fat_write_inode:
      
       - do_unlinkat
         - vfs_unlink
           - vfat_unlink
             * lock_super
             - fat_remove_entries
               - fat_sync_inode
                 - fat_write_inode
                   * lock_super
      
      and the fix is to simply remove the use of lock_super() in fat_write_inode.
      
      The lock_super() there had been just an automatic conversion of the
      kernel lock to the superblock lock, but no locking was actually needed
      there, since the code in fat_write_inode already protected all relevant
      accesses with a spinlock (sbi->inode_hash_lock to be exact).  The only
      code inside the BKL (and thus the superblock lock) was accesses tp local
      variables or calls to functions that have long been SMP-safe (i.e.
      sb_bread, mark_buffe_dirty and brlese).
      
      Bart reports:
       "Looks good.  I ran 10 parallel processes creating 1M files truncating
        them, writing to them again and then deleting them.  This patch fixes
        the issue I ran into.
      
        Signed-off-by: Bart Trojanowski <bart@jukie.net>"
      Reported-and-tested-by: NBart Trojanowski <bart@jukie.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5f22ca9b
    • R
      tracehook: fix SA_NOCLDWAIT · 1b04624f
      Roland McGrath 提交于
      I outwitted myself again in commit 2b2a1ff6,
      and broke the SA_NOCLDWAIT behavior so it leaks zombies.  This fixes it.
      Reported-by: NAndi Kleen <andi@firstfloor.org>
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      1b04624f
    • B
      powerpc: Fix vio_bus_probe oops on probe error · cd5aeb9f
      Brian King 提交于
      When CMO is enabled and booted on a non CMO system and the VIO
      device's probe function fails, an oops can result since
      vio_cmo_bus_remove is called when it should not.  This fixes it by
      avoiding the vio_cmo_bus_remove call on platforms that don't implement
      CMO.
      
      cpu 0x0: Vector: 300 (Data Access) at [c00000000e13b3d0]
          pc: c000000000020d34: .vio_cmo_bus_remove+0xc0/0x1f4
          lr: c000000000020ca4: .vio_cmo_bus_remove+0x30/0x1f4
          sp: c00000000e13b650
         msr: 8000000000009032
         dar: 0
       dsisr: 40000000
        current = 0xc00000000e0566c0
        paca    = 0xc0000000006f9b80
          pid   = 2428, comm = modprobe
      enter ? for help
      [c00000000e13b6e0] c000000000021d94 .vio_bus_probe+0x2f8/0x33c
      [c00000000e13b7a0] c00000000029fc88 .driver_probe_device+0x13c/0x200
      [c00000000e13b830] c00000000029fdac .__driver_attach+0x60/0xa4
      [c00000000e13b8c0] c00000000029f050 .bus_for_each_dev+0x80/0xd8
      [c00000000e13b980] c00000000029f9ec .driver_attach+0x28/0x40
      [c00000000e13ba00] c00000000029f630 .bus_add_driver+0xd4/0x284
      [c00000000e13baa0] c0000000002a01bc .driver_register+0xc4/0x198
      [c00000000e13bb50] c00000000002168c .vio_register_driver+0x40/0x5c
      [c00000000e13bbe0] d0000000003b3f1c .ibmvfc_module_init+0x70/0x109c [ibmvfc]
      [c00000000e13bc70] c0000000000acf08 .sys_init_module+0x184c/0x1a10
      [c00000000e13be30] c000000000008748 syscall_exit+0x0/0x40
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cd5aeb9f
    • J
      powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices · 4589f1fe
      Joachim Fenkes 提交于
      Recent of_platform changes made of_bus_type_init() overwrite the bus
      type's .dev_attrs list, meaning that the "name" attribute that ibmebus
      devices previously had is no longer present.  This is a user-visible
      regression which breaks the userspace eHCA support, since the eHCA
      userspace driver relies on the name attribute to check for valid
      adapters.
      
      This fixes it by providing the "name" attribute in the generic OF
      device code instead.  Tested on POWER.
      Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4589f1fe
    • M
      powerpc: Fix /dev/oldmem interface for kdump · 7230ced4
      Michael Ellerman 提交于
      A change to __ioremap() broke reading /dev/oldmem because we're no
      longer able to ioremap pfn 0 (d177c207, "[PATCH] powerpc: IOMMU: don't
      ioremap null addresses").
      
      We actually don't need to ioremap for anything that's part of the linear
      mapping, so just read it directly.
      
      Also make sure we're only reading one page or less at a time.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NSachin Sant <sachinp@in.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7230ced4