02 Oct, 2010

19 commits

  • …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

    Linus Torvalds
     
  • 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: David Howells
    Acked-by: Akira Takeuchi
    Signed-off-by: Linus Torvalds

    David Howells
     
  • * '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

    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

    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

    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

    Linus Torvalds
     
  • …/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

    Linus Torvalds
     
  • 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: [] do_journal_begin_r+0x7f/0x340 [reiserfs]

    but task is already holding lock:
    (&REISERFS_SB(s)->lock){+.+.+.}, at: [] 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){+.+.+.}:
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_write_lock+0x28/0x40 [reiserfs]
    [] do_journal_begin_r+0x86/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_remount+0x224/0x530 [reiserfs]
    [] do_remount_sb+0x60/0x110
    [] do_mount+0x625/0x790
    [] sys_mount+0x84/0xb0
    [] syscall_call+0x7/0xb

    -> #0 (&journal->j_mutex){+.+...}:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] do_journal_begin_r+0x7f/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
    [] reiserfs_get_block+0x22c/0x1530 [reiserfs]
    [] __block_prepare_write+0x1bb/0x3a0
    [] block_prepare_write+0x26/0x40
    [] reiserfs_prepare_write+0x88/0x170 [reiserfs]
    [] reiserfs_unpack+0xe6/0x120 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] 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: [] reiserfs_unpack+0x6a/0x120 [reiserfs]
    #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    stack backtrace:
    Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3
    Call Trace:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] do_journal_begin_r+0x7f/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
    [] reiserfs_get_block+0x22c/0x1530 [reiserfs]
    [] __block_prepare_write+0x1bb/0x3a0
    [] block_prepare_write+0x26/0x40
    [] reiserfs_prepare_write+0x88/0x170 [reiserfs]
    [] reiserfs_unpack+0xe6/0x120 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    Reported-by: Jarek Poplawski
    Tested-by: Jarek Poplawski
    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: All since 2.6.32
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: [] reiserfs_unpack+0x60/0x110 [reiserfs]

    but task is already holding lock:
    (&REISERFS_SB(s)->lock){+.+.+.}, at: [] 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){+.+.+.}:
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_write_lock+0x28/0x40 [reiserfs]
    [] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs]
    [] reiserfs_fill_super+0x941/0xe60 [reiserfs]
    [] get_sb_bdev+0x117/0x170
    [] get_super_block+0x21/0x30 [reiserfs]
    [] vfs_kern_mount+0x6a/0x1b0
    [] do_kern_mount+0x39/0xe0
    [] do_mount+0x340/0x790
    [] sys_mount+0x84/0xb0
    [] syscall_call+0x7/0xb

    -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_unpack+0x60/0x110 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    other info that might help us debug this:

    1 lock held by lilo/1606:
    #0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    stack backtrace:
    Pid: 1606, comm: lilo Not tainted 2.6.35c #13
    Call Trace:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_unpack+0x60/0x110 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    Reported-by: Jarek Poplawski
    Tested-by: Jarek Poplawski
    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: [2.6.32 and later]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederic Weisbecker
     
  • Signed-off-by: Kukjin Kim
    Acked-by: Ben Dooks
    Acked-by: Russell King
    Cc: Kyungmin Park
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kukjin Kim
     
  • 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: Petr Vandrovec
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Petr Vandrovec
     
  • 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: Jiri Olsa
    Acked-by: Neil Horman
    Cc: Eugene Teo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Olsa
     
  • 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: Don Mullis
    Tested-by: Artem Bityutskiy
    Signed-off-by: Artem Bityutskiy
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Don Mullis
     
  • 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: Dan Rosenberg
    Cc: Manfred Spraul
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dan Rosenberg
     
  • 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: [] 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:[] [] edac_create_mci_instance_attributes+0x148/0x1f1
    (...)
    Call Trace:
    [] edac_create_mci_instance_attributes+0x198/0x1f1
    [] edac_create_sysfs_mci_device+0xbb/0x2b2
    [] edac_mc_add_mc+0x46b/0x557
    [] i7core_probe+0xccf/0xec0
    RIP [] edac_create_mci_instance_attributes+0x148/0x1f1
    ---[ end trace 20de320855b81d78 ]---
    Kernel panic - not syncing: Attempted to kill init!

    Signed-off-by: Marcin Slusarz
    Cc: Mauro Carvalho Chehab
    Acked-by: Doug Thompson
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marcin Slusarz
     
  • 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • 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: Ira W. Snyder
    Cc: Stefani Seibold
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ira W. Snyder
     

01 Oct, 2010

11 commits

  • If the soon-to-be scanout buffer is partly covering the intended
    VRAM region, move and pin will fail. In that case, just move it out
    to system before attempting to move it in again.

    Signed-off-by: Thomas Hellstrom
    Signed-off-by: Dave Airlie

    Thomas Hellstrom
     
  • The removed code causes oopses with newer drms on master drop.

    Signed-off-by: Thomas Hellstrom
    Signed-off-by: Dave Airlie

    Thomas Hellstrom
     
  • This is to avoid accessing uninitialized data during
    drm_irq_uninstall and vblank ioctls. At the same time, enable error check from
    drm_kms_init which previously appeared to ignore all errors.

    Signed-off-by: Thomas Hellstrom
    Signed-off-by: Dave Airlie

    Thomas Hellstrom
     
  • We add an option not to enable fbdev, this option is off (0) by default.
    Not enabling fbdev at load time makes it possible to co-operate with
    vga16fb and vga text mode when VT switching.

    However, if 3D resources are active when VT switching, we're currently
    not able to switch over to vga, due to device limitations.
    This fixes a bug where we previously lost 3D state during VT switch.

    Signed-off-by: Thomas Hellstrom
    Signed-off-by: Dave Airlie

    Thomas Hellstrom
     
  • …ting buffer and having drivers overwrite it (v2)"

    The mentioned commit breaks the vmwgfx ioctl argument sanity check.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

    Thomas Hellstrom
     
  • In order to be fully threadsafe we need to check that the drm_gem_object
    refcount is still 0 after acquiring the mutex in order to call the free
    function. Otherwise, we may encounter scenarios like:

    Thread A: Thread B:
    drm_gem_close
    unreference_unlocked
    kref_put mutex_lock
    ... i915_gem_evict
    ... kref_get -> BUG
    ... i915_gem_unbind
    ... kref_put
    ... i915_gem_object_free
    ... mutex_unlock
    mutex_lock
    i915_gem_object_free -> BUG
    i915_gem_object_unbind
    kfree
    mutex_unlock

    Note that no driver is currently using the free_unlocked vfunc and it is
    scheduled for removal, hasten that process.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454
    Reported-and-Tested-by: Magnus Kessler
    Signed-off-by: Chris Wilson
    Cc: stable@kernel.org
    Signed-off-by: Dave Airlie

    Chris Wilson
     
  • Avoid TLB flush IPIs for the cores in deeper c-states by voluntary leave_mm()
    before entering into that state. CPUs tend to flush TLB in those c-states
    anyways.

    acpi_idle does this with C3-type states, but it was not caried over
    when intel_idle was introduced. intel_idle can apply it
    to C-states in addition to those that ACPI might export as C3...

    Signed-off-by: Suresh Siddha
    Signed-off-by: Len Brown

    Suresh Siddha
     
  • There were lots of places being inconsistent since handle count
    looked like a kref but it really wasn't.

    Fix this my just making handle count an atomic on the object,
    and have it increase the normal object kref.

    Now i915/radeon/nouveau drivers can drop the normal reference on
    userspace object creation, and have the handle hold it.

    This patch fixes a memory leak or corruption on unload, because
    the driver had no way of knowing if a handle had been actually
    added for this object, and the fbcon object needed to know this
    to clean itself up properly.

    Reviewed-by: Chris Wilson
    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • S3C2440 style I2C controller uses PCLK to calculate the SDA line delay.
    The driver wrongly assumed that this delay is calculated from the
    frequency that the controller is operating on. This patch fixes this
    issue.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Signed-off-by: Marek Szyprowski
    Signed-off-by: Ben Dooks

    MyungJoo Ham
     
  • create_irq() returns -1 if the interrupt allocation failed, but the
    code checks for irq == 0.

    Use create_irq_nr() instead.

    Signed-off-by: Thomas Gleixner
    Cc: Venkatesh Pallipadi
    LKML-Reference:
    Cc: stable@kernel.org
    Signed-off-by: H. Peter Anvin

    Thomas Gleixner
     
  • free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this
    triggers a use after free caused by the fact that copying struct
    irq_cfg is done with memcpy, which copies the pointer not the cpumask.

    Fix both places.

    Signed-off-by: Thomas Gleixner
    Cc: Yinghai Lu
    LKML-Reference:
    Signed-off-by: Thomas Gleixner
    Cc: stable@kernel.org
    Signed-off-by: H. Peter Anvin

    Thomas Gleixner
     

30 Sep, 2010

10 commits