1. 05 Oct, 2010 4 commits
    • Linus Torvalds's avatar
      Merge branch 'core-fixes-for-linus' of... · e1d9694c
      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:
        rcu: rcu_read_lock_bh_held(): disabling irqs also disables bh
        generic-ipi: Fix deadlock in __smp_call_function_single
      e1d9694c
    • Linus Torvalds's avatar
      Merge branch 'perf-fixes-for-linus' of... · 39c12be8
      Linus Torvalds authored
      Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
      
      * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
        perf trace scripting: Fix extern struct definitions
        perf ui hist browser: Fix segfault on 'a' for annotate
        perf tools: Fix build breakage
        perf, x86: Handle in flight NMIs on P4 platform
        oprofile, ARM: Release resources on failure
        oprofile: Add Support for Intel CPU Family 6 / Model 29
      39c12be8
    • Evgeny Kuznetsov's avatar
      wait: using uninitialized member of wait queue · 231d0aef
      Evgeny Kuznetsov authored
      The "flags" member of "struct wait_queue_t" is used in several places in
      the kernel code without beeing initialized by init_wait().  "flags" is
      used in bitwise operations.
      
      If "flags" not initialized then unexpected behaviour may take place.
      Incorrect flags might used later in code.
      
      Added initialization of "wait_queue_t.flags" with zero value into
      "init_wait".
      Signed-off-by: default avatarEvgeny Kuznetsov <EXT-Eugeny.Kuznetsov@nokia.com>
      [ The bit we care about does end up being initialized by both
         prepare_to_wait() and add_to_wait_queue(), so this doesn't seem to
         cause actual bugs, but is definitely the right thing to do -Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      231d0aef
    • Linus Torvalds's avatar
      modules: Fix module_bug_list list corruption race · 5336377d
      Linus Torvalds authored
      With all the recent module loading cleanups, we've minimized the code
      that sits under module_mutex, fixing various deadlocks and making it
      possible to do most of the module loading in parallel.
      
      However, that whole conversion totally missed the rather obscure code
      that adds a new module to the list for BUG() handling.  That code was
      doubly obscure because (a) the code itself lives in lib/bugs.c (for
      dubious reasons) and (b) it gets called from the architecture-specific
      "module_finalize()" rather than from generic code.
      
      Calling it from arch-specific code makes no sense what-so-ever to begin
      with, and is now actively wrong since that code isn't protected by the
      module loading lock any more.
      
      So this commit moves the "module_bug_{finalize,cleanup}()" calls away
      from the arch-specific code, and into the generic code - and in the
      process protects it with the module_mutex so that the list operations
      are now safe.
      
      Future fixups:
       - move the module list handling code into kernel/module.c where it
         belongs.
       - get rid of 'module_bug_list' and just use the regular list of modules
         (called 'modules' - imagine that) that we already create and maintain
         for other reasons.
      Reported-and-tested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Adrian Bunk <bunk@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5336377d
  2. 04 Oct, 2010 13 commits
  3. 03 Oct, 2010 7 commits
  4. 02 Oct, 2010 4 commits
  5. 01 Oct, 2010 12 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 · c6ea21e3
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
        cifs: prevent infinite recursion in cifs_reconnect_tcon
        cifs: set backing_dev_info on new S_ISREG inodes
      c6ea21e3
    • Linus Torvalds's avatar
      Merge branch 'x86-fixes-for-linus' of... · f4a3330d
      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, hpet: Fix bogus error check in hpet_assign_irq()
        x86, irq: Plug memory leak in sparse irq
        x86, cpu: After uncapping CPUID, re-run CPU feature detection
      f4a3330d
    • David Howells's avatar
      MN10300: Fix flush_icache_range() · 57cf4f78
      David Howells authored
      flush_icache_range() is given virtual addresses to describe the region.  It
      deals with these by attempting to translate them through the current set of
      page tables.
      
      This is fine for userspace memory and vmalloc()'d areas as they are governed by
      page tables.  However, since the regions above 0x80000000 aren't translated
      through the page tables by the MMU, the kernel doesn't bother to set up page
      tables for them (see paging_init()).
      
      This means flush_icache_range() as it stands cannot be used to flush regions of
      the VM area between 0x80000000 and 0x9fffffff where the kernel resides if the
      data cache is operating in WriteBack mode.
      
      To fix this, make flush_icache_range() first check for addresses in the upper
      half of VM space and deal with them appropriately, before dealing with any
      range in the page table mapped area.
      
      Ordinarily, this is not a problem, but it has the capacity to make kprobes and
      kgdb malfunction.  It should not affect gdbstub, signal frame setup or module
      loading as gdb has its own flush functions, and the others take place in the
      page table mapped area only.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarAkira Takeuchi <takeuchi.akr@jp.panasonic.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57cf4f78
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 · 18ffe4b1
      Linus Torvalds authored
      * 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
        vmwgfx: Fix fb VRAM pinning failure due to fragmentation
        vmwgfx: Remove initialisation of dev::devname
        vmwgfx: Enable use of the vblank system
        vmwgfx: vt-switch (master drop) fixes
        drm/vmwgfx: Fix breakage introduced by commit "drm: block userspace under allocating buffer and having drivers overwrite it (v2)"
        drm: Hold the mutex when dropping the last GEM reference (v2)
        drm/gem: handlecount isn't really a kref so don't make it one.
        drm: i810/i830: fix locked ioctl variant
        drm/radeon/kms: add quirk for MSI K9A2GM motherboard
        drm/radeon/kms: fix potential segfault in r600_ioctl_wait_idle
        drm: Prune GEM vma entries
        drm/radeon/kms: fix up encoder info messages for DFP6
        drm/radeon: fix PCI ID 5657 to be an RV410
      18ffe4b1
    • Linus Torvalds's avatar
      Merge branch 'for-linus/i2c/2636-rc5' of git://git.fluff.org/bjdooks/linux · b10c4d40
      Linus Torvalds authored
      * 'for-linus/i2c/2636-rc5' of git://git.fluff.org/bjdooks/linux:
        i2c-s3c2410: fix calculation of SDA line delay
        i2c-davinci: Fix race when setting up for TX
        i2c-octeon: Return -ETIMEDOUT in octeon_i2c_wait() on timeout
      b10c4d40
    • Linus Torvalds's avatar
      Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 · 303a4070
      Linus Torvalds authored
      * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
        ACPI: invoke DSDT corruption workaround on all Toshiba Satellite
        ACPI, APEI, Fix ERST MOVE_DATA instruction implementation
        ACPI: fan: Fix more unbalanced code block
        ACPI: acpi_pad: simplify code to avoid false gcc build warning
        ACPI, APEI, Fix error path for memory allocation
        ACPI, APEI, HEST Fix the unsuitable usage of platform_data
        ACPI, APEI, Fix acpi_pre_map() return value
        ACPI, APEI, Fix APEI related table size checking
        ACPI: Disable Windows Vista compatibility for Toshiba P305D
        ACPI: Kconfig: fix typo.
        ACPI: add missing __percpu markup in arch/x86/kernel/acpi/cstate.c
        ACPI: Fix typos
        ACPI video: fix a poor warning message
        ACPI: fix build warnings resulting from merge window conflict
        ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355
        ACPI: expand Vista blacklist to include SP1 and SP2
        ACPI: delete ZEPTO idle=nomwait DMI quirk
        ACPI: enable repeated PCIEXP wakeup by clearing PCIEXP_WAKE_STS on resume
        PM / ACPI: Blacklist systems known to require acpi_sleep=nonvs
        ACPI: Don't report current_now if battery reports in mWh
      303a4070
    • Linus Torvalds's avatar
      Merge branch 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6 · 35ec4216
      Linus Torvalds authored
      * 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6:
        intel_idle: Voluntary leave_mm before entering deeper
        acpi_idle: add missing \n to printk
        intel_idle: add missing __percpu markup
        intel_idle: Change mode 755 => 644
        cpuidle: Fix typos
        intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang
      35ec4216
    • Linus Torvalds's avatar
      Merge branch 'omap-fixes-for-linus' of... · 3c729087
      Linus Torvalds authored
      Merge branch 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6
      
      * 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
        omap: McBSP: tx_irq_completion used in rx_irq_handler
        omap: Fix compile dependency to LEDS_CLASS
      3c729087
    • Frederic Weisbecker's avatar
      reiserfs: fix unwanted reiserfs lock recursion · 9d8117e7
      Frederic Weisbecker authored
      Prevent from recursively locking the reiserfs lock in reiserfs_unpack()
      because we may call journal_begin() that requires the lock to be taken
      only once, otherwise it won't be able to release the lock while taking
      other mutexes, ending up in inverted dependencies between the journal
      mutex and the reiserfs lock for example.
      
      This fixes:
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        2.6.35.4.4a #3
        -------------------------------------------------------
        lilo/1620 is trying to acquire lock:
         (&journal->j_mutex){+.+...}, at: [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
      
        but task is already holding lock:
         (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
               [<c10562b7>] lock_acquire+0x67/0x80
               [<c12facad>] __mutex_lock_common+0x4d/0x410
               [<c12fb0c8>] mutex_lock_nested+0x18/0x20
               [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
               [<d0325c06>] do_journal_begin_r+0x86/0x340 [reiserfs]
               [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
               [<d0315be4>] reiserfs_remount+0x224/0x530 [reiserfs]
               [<c10b6a20>] do_remount_sb+0x60/0x110
               [<c10cee25>] do_mount+0x625/0x790
               [<c10cf014>] sys_mount+0x84/0xb0
               [<c12fca3d>] syscall_call+0x7/0xb
      
        -> #0 (&journal->j_mutex){+.+...}:
               [<c10560f6>] __lock_acquire+0x1026/0x1180
               [<c10562b7>] lock_acquire+0x67/0x80
               [<c12facad>] __mutex_lock_common+0x4d/0x410
               [<c12fb0c8>] mutex_lock_nested+0x18/0x20
               [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
               [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
               [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
               [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs]
               [<c10db9db>] __block_prepare_write+0x1bb/0x3a0
               [<c10dbbe6>] block_prepare_write+0x26/0x40
               [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs]
               [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs]
               [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs]
               [<c10c3188>] vfs_ioctl+0x28/0xa0
               [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0
               [<c10c3eb3>] sys_ioctl+0x63/0x70
               [<c12fca3d>] syscall_call+0x7/0xb
      
        other info that might help us debug this:
      
        2 locks held by lilo/1620:
         #0:  (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d032945a>] reiserfs_unpack+0x6a/0x120 [reiserfs]
         #1:  (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a278>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        stack backtrace:
        Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3
        Call Trace:
         [<c10560f6>] __lock_acquire+0x1026/0x1180
         [<c10562b7>] lock_acquire+0x67/0x80
         [<c12facad>] __mutex_lock_common+0x4d/0x410
         [<c12fb0c8>] mutex_lock_nested+0x18/0x20
         [<d0325bff>] do_journal_begin_r+0x7f/0x340 [reiserfs]
         [<d0325f77>] journal_begin+0x77/0x140 [reiserfs]
         [<d0326271>] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
         [<d030d06c>] reiserfs_get_block+0x22c/0x1530 [reiserfs]
         [<c10db9db>] __block_prepare_write+0x1bb/0x3a0
         [<c10dbbe6>] block_prepare_write+0x26/0x40
         [<d030b738>] reiserfs_prepare_write+0x88/0x170 [reiserfs]
         [<d03294d6>] reiserfs_unpack+0xe6/0x120 [reiserfs]
         [<d0329782>] reiserfs_ioctl+0x272/0x320 [reiserfs]
         [<c10c3188>] vfs_ioctl+0x28/0xa0
         [<c10c3bbd>] do_vfs_ioctl+0x32d/0x5c0
         [<c10c3eb3>] sys_ioctl+0x63/0x70
         [<c12fca3d>] syscall_call+0x7/0xb
      Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: All since 2.6.32 <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9d8117e7
    • Frederic Weisbecker's avatar
      reiserfs: fix dependency inversion between inode and reiserfs mutexes · 3f259d09
      Frederic Weisbecker authored
      The reiserfs mutex already depends on the inode mutex, so we can't lock
      the inode mutex in reiserfs_unpack() without using the safe locking API,
      because reiserfs_unpack() is always called with the reiserfs mutex locked.
      
      This fixes:
      
        =======================================================
        [ INFO: possible circular locking dependency detected ]
        2.6.35c #13
        -------------------------------------------------------
        lilo/1606 is trying to acquire lock:
         (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
      
        but task is already holding lock:
         (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
               [<c1056347>] lock_acquire+0x67/0x80
               [<c12f083d>] __mutex_lock_common+0x4d/0x410
               [<c12f0c58>] mutex_lock_nested+0x18/0x20
               [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
               [<d0329e9a>] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs]
               [<d0316b81>] reiserfs_fill_super+0x941/0xe60 [reiserfs]
               [<c10b7d17>] get_sb_bdev+0x117/0x170
               [<d0313e21>] get_super_block+0x21/0x30 [reiserfs]
               [<c10b74ba>] vfs_kern_mount+0x6a/0x1b0
               [<c10b7659>] do_kern_mount+0x39/0xe0
               [<c10cebe0>] do_mount+0x340/0x790
               [<c10cf0b4>] sys_mount+0x84/0xb0
               [<c12f25cd>] syscall_call+0x7/0xb
      
        -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}:
               [<c1056186>] __lock_acquire+0x1026/0x1180
               [<c1056347>] lock_acquire+0x67/0x80
               [<c12f083d>] __mutex_lock_common+0x4d/0x410
               [<c12f0c58>] mutex_lock_nested+0x18/0x20
               [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
               [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs]
               [<c10c3228>] vfs_ioctl+0x28/0xa0
               [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0
               [<c10c3f53>] sys_ioctl+0x63/0x70
               [<c12f25cd>] syscall_call+0x7/0xb
      
        other info that might help us debug this:
      
        1 lock held by lilo/1606:
         #0:  (&REISERFS_SB(s)->lock){+.+.+.}, at: [<d032a268>] reiserfs_write_lock+0x28/0x40 [reiserfs]
      
        stack backtrace:
        Pid: 1606, comm: lilo Not tainted 2.6.35c #13
        Call Trace:
         [<c1056186>] __lock_acquire+0x1026/0x1180
         [<c1056347>] lock_acquire+0x67/0x80
         [<c12f083d>] __mutex_lock_common+0x4d/0x410
         [<c12f0c58>] mutex_lock_nested+0x18/0x20
         [<d0329450>] reiserfs_unpack+0x60/0x110 [reiserfs]
         [<d0329772>] reiserfs_ioctl+0x272/0x320 [reiserfs]
         [<c10c3228>] vfs_ioctl+0x28/0xa0
         [<c10c3c5d>] do_vfs_ioctl+0x32d/0x5c0
         [<c10c3f53>] sys_ioctl+0x63/0x70
         [<c12f25cd>] syscall_call+0x7/0xb
      Reported-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: <stable@kernel.org>		[2.6.32 and later]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3f259d09
    • Kukjin Kim's avatar
      MAINTAINERS: update maintainer for S5P ARM ARCHITECTURES · f556cb07
      Kukjin Kim authored
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Acked-by: default avatarBen Dooks <ben-linux@fluff.org>
      Acked-by: default avatarRussell King <rmk@arm.linux.org.uk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f556cb07
    • Petr Vandrovec's avatar
      MAINTAINERS: update matroxfb & ncpfs status · 52653199
      Petr Vandrovec authored
      I moved couple years ago, so let's update my email and snail mail.
      
      And I do not have any access to Matrox hardware anymore, and I'm quite
      unresponsive to matroxfb bug reports (sorry Alan), so saying that I'm
      maintainer is a bit far fetched.
      
      For ncpfs I do not use ncpfs in my daily life either, but at least I can
      test that one, so I can stay listed here for odd fixes.
      Signed-off-by: default avatarPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      52653199