1. 13 10月, 2010 1 次提交
  2. 08 10月, 2010 2 次提交
    • T
      ARM: 6435/1: Fix HWCAP_TLS flag for ARM11MPCore/Cortex-A9 · c0bb5862
      Tony Lindgren 提交于
      Commit 14eff181 added proper
      detection for ARM11MPCore/Cortex-A9 instead of detecting them
      as ARMv7. However, it was missing the HWCAP_TLS flags.
      
      HWCAP_TLS is needed if support for earlier ARMv6 is compiled
      into the same kernel. Without HWCAP_TLS flags the userspace
      won't work unless nosmp is specified:
      
      Kernel panic - not syncing: Attempted to kill init!
      CPU0: stopping
      <c005d5e4>] (unwind_backtrace+0x0/0xec) from [<c004c2f8>] (do_IPI+0xfc/0x184)
      <c004c2f8>] (do_IPI+0xfc/0x184) from [<c03f25bc>] (__irq_svc+0x9c/0x160)
      Exception stack(0xc0565f80 to 0xc0565fc8)
      5f80: 00000001 c05772a0 00000000 00003a61 c0564000 c05cf500 c003603c c0578600
      5fa0: 80033ef0 410fc091 0000001f 00000000 00000000 c0565fc8 c00b91f8 c0057cb4
      5fc0: 20000013 ffffffff
      [<c03f25bc>] (__irq_svc+0x9c/0x160) from [<c0057cb4>] (default_idle+0x30/0x38)
      [<c0057cb4>] (default_idle+0x30/0x38) from [<c005829c>] (cpu_idle+0x9c/0xf8)
      [<c005829c>] (cpu_idle+0x9c/0xf8) from [<c0008d48>] (start_kernel+0x2a4/0x300)
      [<c0008d48>] (start_kernel+0x2a4/0x300) from [<80008084>] (0x80008084)
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0bb5862
    • A
      ARM: 6436/1: AT91: Fix power-saving in idle-mode on 926T processors · 5c189208
      Anders Larsen 提交于
      According to Atmel, their 926T processors (AT91 post RM9200) requires
      'Wait for Interrupt' mode be entered right after disabling the processor clock
      in order to minimise current consumption when idle, so do both provided we're
      not running on a 920T (an RM9200).
      
      Furthermore, get rid of the #ifndef CONFIG_DEBUG_KERNEL, since arch_idle()
      can be turned off completely with the kernel parameter 'nohlt'.
      
      Cc: Andrew Victor <avictor.za@gmail.com>
      Signed-off-by: NAnders Larsen <al@alarsen.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5c189208
  3. 05 10月, 2010 4 次提交
    • R
      ARM: fix section mismatch warnings in Versatile Express · cdaf9a2f
      Russell King 提交于
      WARNING: vmlinux.o(.text+0xbf30): Section mismatch in reference from the function v2m_timer_init() to the function .init.text:sp804_clocksource_init()
      The function v2m_timer_init() references
      the function __init sp804_clocksource_init().
      This is often because v2m_timer_init lacks a __init
      annotation or the annotation of sp804_clocksource_init is wrong.
      
      WARNING: vmlinux.o(.text+0xbf3c): Section mismatch in reference from the function v2m_timer_init() to the function .init.text:sp804_clockevents_init()
      The function v2m_timer_init() references
      the function __init sp804_clockevents_init().
      This is often because v2m_timer_init lacks a __init
      annotation or the annotation of sp804_clockevents_init is wrong.
      
      WARNING: vmlinux.o(.text+0xc524): Section mismatch in reference from the function ct_ca9x4_init() to the function .init.text:l2x0_init()
      The function ct_ca9x4_init() references
      the function __init l2x0_init().
      This is often because ct_ca9x4_init lacks a __init
      annotation or the annotation of l2x0_init is wrong.
      
      WARNING: vmlinux.o(.text+0xc530): Section mismatch in reference from the function ct_ca9x4_init() to the function .init.text:clkdev_add_table()
      The function ct_ca9x4_init() references
      the function __init clkdev_add_table().
      This is often because ct_ca9x4_init lacks a __init
      annotation or the annotation of clkdev_add_table is wrong.
      
      WARNING: vmlinux.o(.text+0xc578): Section mismatch in reference from the function ct_ca9x4_init() to the (unknown reference) .init.data:(unknown)
      The function ct_ca9x4_init() references
      the (unknown reference) __initdata (unknown).
      This is often because ct_ca9x4_init lacks a __initdata
      annotation or the annotation of (unknown) is wrong.
      
      Fix these by making ct_ca9x4_init() and v2m_timer_init() both __init.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      cdaf9a2f
    • W
      ARM: 6412/1: kprobes-decode: add support for MOVW instruction · ccdf2e1b
      Will Deacon 提交于
      The MOVW instruction moves a 16-bit immediate into the bottom halfword
      of the destination register.
      
      This patch ensures that kprobes leaves the 16-bit immediate intact, rather
      than assume a 12-bit immediate and mask out the upper 4 bits.
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ccdf2e1b
    • S
      ARM: 6419/1: mmu: Fix MT_MEMORY and MT_MEMORY_NONCACHED pte flags · 7f58217b
      Santosh Shilimkar 提交于
      The commit f1a2481c sets up the default flags for MT_MEMORY and
      MT_MEMORY_NONCACHED memory types. L_PTE_USER flag is wrongly
      set as default for these entries so remove it. Also adding
      the 'L_PTE_WRITE' flag so that these pages become read-write
      instead of just being read-only
      
      [this stops them being exposed to userspace, which is the main
      concern here --rmk]
      Reported-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7f58217b
    • W
      ARM: 6416/1: errata: faulty hazard checking in the Store Buffer may lead to data corruption · 475d92fc
      Will Deacon 提交于
      On the r2p0, r2p1 and r2p2 versions of the Cortex-A9, data corruption
      can occur under very rare conditions due to a store buffer optimisation.
      
      This workaround sets a bit in the diagnostic register of the Cortex-A9,
      disabling the optimisation and preventing the problem from occurring.
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      475d92fc
  4. 02 10月, 2010 21 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 · c6ea21e3
      Linus Torvalds 提交于
      * 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
    • L
      Merge branch 'x86-fixes-for-linus' of... · f4a3330d
      Linus Torvalds 提交于
      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
    • D
      MN10300: Fix flush_icache_range() · 57cf4f78
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Acked-by: NAkira Takeuchi <takeuchi.akr@jp.panasonic.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57cf4f78
    • L
      Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 · 18ffe4b1
      Linus Torvalds 提交于
      * '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
    • L
      Merge branch 'for-linus/i2c/2636-rc5' of git://git.fluff.org/bjdooks/linux · b10c4d40
      Linus Torvalds 提交于
      * '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
    • L
      Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 · 303a4070
      Linus Torvalds 提交于
      * '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
    • L
      Merge branch 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6 · 35ec4216
      Linus Torvalds 提交于
      * '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
    • L
      Merge branch 'omap-fixes-for-linus' of... · 3c729087
      Linus Torvalds 提交于
      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
    • F
      reiserfs: fix unwanted reiserfs lock recursion · 9d8117e7
      Frederic Weisbecker 提交于
      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: NJarek Poplawski <jarkao2@gmail.com>
      Tested-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: All since 2.6.32 <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9d8117e7
    • F
      reiserfs: fix dependency inversion between inode and reiserfs mutexes · 3f259d09
      Frederic Weisbecker 提交于
      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: NJarek Poplawski <jarkao2@gmail.com>
      Tested-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: <stable@kernel.org>		[2.6.32 and later]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3f259d09
    • K
      MAINTAINERS: update maintainer for S5P ARM ARCHITECTURES · f556cb07
      Kukjin Kim 提交于
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Acked-by: NBen Dooks <ben-linux@fluff.org>
      Acked-by: NRussell King <rmk@arm.linux.org.uk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f556cb07
    • P
      MAINTAINERS: update matroxfb & ncpfs status · 52653199
      Petr Vandrovec 提交于
      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: NPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52653199
    • J
      proc: make /proc/pid/limits world readable · 3036e7b4
      Jiri Olsa 提交于
      Having the limits file world readable will ease the task of system
      management on systems where root privileges might be restricted.
      
      Having admin restricted with root priviledges, he/she could not check
      other users process' limits.
      
      Also it'd align with most of the /proc stat files.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Cc: Eugene Teo <eugene@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3036e7b4
    • D
      lib/list_sort: do not pass bad pointers to cmp callback · f015ac3e
      Don Mullis 提交于
      If the original list is a POT in length, the first callback from line 73
      will pass a==b both pointing to the original list_head.  This is dangerous
      because the 'list_sort()' user can use 'container_of()' and accesses the
      "containing" object, which does not necessary exist for the list head.  So
      the user can access RAM which does not belong to him.  If this is a write
      access, we can end up with memory corruption.
      Signed-off-by: NDon Mullis <don.mullis@gmail.com>
      Tested-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f015ac3e
    • D
      sys_semctl: fix kernel stack leakage · 982f7c2b
      Dan Rosenberg 提交于
      The semctl syscall has several code paths that lead to the leakage of
      uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO,
      IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete
      version of the semid_ds struct.
      
      The copy_semid_to_user() function declares a semid_ds struct on the stack
      and copies it back to the user without initializing or zeroing the
      "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers,
      allowing the leakage of 16 bytes of kernel stack memory.
      
      The code is still reachable on 32-bit systems - when calling semctl()
      newer glibc's automatically OR the IPC command with the IPC_64 flag, but
      invoking the syscall directly allows users to use the older versions of
      the struct.
      Signed-off-by: NDan Rosenberg <dan.j.rosenberg@gmail.com>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      982f7c2b
    • M
      i7core_edac: fix panic in udimm sysfs attributes registration · 64aab720
      Marcin Slusarz 提交于
      Array of udimm sysfs attributes was not ended with NULL marker, leading to
      dereference of random memory.
      
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm0
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm1
        EDAC DEBUG: edac_create_mci_instance_attributes: edac_create_mci_instance_attributes() file udimm2
        BUG: unable to handle kernel NULL pointer dereference at 00000000000001a4
        IP: [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        Pid: 1, comm: swapper Not tainted 2.6.36-rc3-nv+ #483 P6T SE/System Product Name
        RIP: 0010:[<ffffffff81330b36>]  [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        (...)
        Call Trace:
         [<ffffffff81330b86>] edac_create_mci_instance_attributes+0x198/0x1f1
         [<ffffffff81330c9a>] edac_create_sysfs_mci_device+0xbb/0x2b2
         [<ffffffff8132f533>] edac_mc_add_mc+0x46b/0x557
         [<ffffffff81428901>] i7core_probe+0xccf/0xec0
        RIP  [<ffffffff81330b36>] edac_create_mci_instance_attributes+0x148/0x1f1
        ---[ end trace 20de320855b81d78 ]---
        Kernel panic - not syncing: Attempted to kill init!
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: NDoug Thompson <dougthompson@xmission.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      64aab720
    • A
      drivers/serial/mrst_max3110.c needs linux/irq.h · c044391b
      Andrew Morton 提交于
      sparc64 allmodconfig:
      
        drivers/serial/mrst_max3110.c: In function `serial_m3110_startup':
        drivers/serial/mrst_max3110.c:470: error: `IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function)
      
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c044391b
    • A
      arch/m68k/mac/macboing.c: use unsigned long for irqflags · e53ced1b
      Andrew Morton 提交于
      Fix the warnings
      
        arch/m68k/mac/macboing.c: In function 'mac_mksound':
        arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell':
        arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast
        arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell':
        arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast
      
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e53ced1b
    • A
      drivers/serial/mfd.c needs slab.h · 63d66cab
      Andrew Morton 提交于
      alpha allmodconfig:
      
        drivers/serial/mfd.c:144: error: implicit declaration of function 'kzalloc'
        drivers/serial/mfd.c:144: warning: assignment makes pointer from integer without a cast
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      63d66cab
    • I
      kfifo: fix scatterlist usage · 399f1e30
      Ira W. Snyder 提交于
      The kfifo_dma family of functions use sg_mark_end() on the last element in
      their scatterlist.  This forces use of a fresh scatterlist for each DMA
      operation, which makes recycling a single scatterlist impossible.
      
      Change the behavior of the kfifo_dma functions to match the usage of the
      dma_map_sg function.  This means that users must respect the returned
      nents value.  The sample code is updated to reflect the change.
      
      This bug is trivial to cause: call kfifo_dma_in_prepare() such that it
      prepares a scatterlist with a single entry comprising the whole fifo.
      This is the case when you map the entirety of a newly created empty fifo.
      This causes the setup_sgl() function to mark the first scatterlist entry
      as the end of the chain, no matter what comes after it.
      
      Afterwards, add and remove some data from the fifo such that another call
      to kfifo_dma_in_prepare() will create two scatterlist entries.  It returns
      nents=2.  However, due to the previous sg_mark_end() call, sg_is_last()
      will now return true for the first scatterlist element.  This causes the
      sample code to print a single scatterlist element when it should print
      two.
      
      By removing the call to sg_mark_end(), we make the API as similar as
      possible to the DMA mapping API.  All users are required to respect the
      returned nents.
      Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
      Cc: Stefani Seibold <stefani@seibold.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      399f1e30
    • J
      cifs: prevent infinite recursion in cifs_reconnect_tcon · f569599a
      Jeff Layton 提交于
      cifs_reconnect_tcon is called from smb_init. After a successful
      reconnect, cifs_reconnect_tcon will call reset_cifs_unix_caps. That
      function will, in turn call CIFSSMBQFSUnixInfo and CIFSSMBSetFSUnixInfo.
      Those functions also call smb_init.
      
      It's possible for the session and tcon reconnect to succeed, and then
      for another cifs_reconnect to occur before CIFSSMBQFSUnixInfo or
      CIFSSMBSetFSUnixInfo to be called. That'll cause those functions to call
      smb_init and cifs_reconnect_tcon again, ad infinitum...
      
      Break the infinite recursion by having those functions use a new
      smb_init variant that doesn't attempt to perform a reconnect.
      Reported-and-Tested-by: NMichal Suchanek <hramrach@centrum.cz>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f569599a
  5. 01 10月, 2010 11 次提交
  6. 30 9月, 2010 1 次提交