Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on May 9, 2011
  1. @gregkh

    Linux 2.6.38.6

    gregkh authored
  2. @torvalds @gregkh

    VM: skip the stack guard page lookup in get_user_pages only for mlock

    torvalds authored gregkh committed
    commit a1fde08 upstream.
    
    The logic in __get_user_pages() used to skip the stack guard page lookup
    whenever the caller wasn't interested in seeing what the actual page
    was.  But Michel Lespinasse points out that there are cases where we
    don't care about the physical page itself (so 'pages' may be NULL), but
    do want to make sure a page is mapped into the virtual address space.
    
    So using the existence of the "pages" array as an indication of whether
    to look up the guard page or not isn't actually so great, and we really
    should just use the FOLL_MLOCK bit.  But because that bit was only set
    for the VM_LOCKED case (and not all vma's necessarily have it, even for
    mlock()), we couldn't do that originally.
    
    Fix that by moving the VM_LOCKED check deeper into the call-chain, which
    actually simplifies many things.  Now mlock() gets simpler, and we can
    also check for FOLL_MLOCK in __get_user_pages() and the code ends up
    much more straightforward.
    
    Reported-and-reviewed-by: Michel Lespinasse <walken@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    fix oops in scsi_run_queue()

    James Bottomley authored gregkh committed
    commit c055f5b upstream.
    
    The recent commit closing the race window in device teardown:
    
    commit 86cbfb5
    Author: James Bottomley <James.Bottomley@suse.de>
    Date:   Fri Apr 22 10:39:59 2011 -0500
    
        [SCSI] put stricter guards on queue dead checks
    
    is causing a potential NULL deref in scsi_run_queue() because the
    q->queuedata may already be NULL by the time this function is called.
    Since we shouldn't be running a queue that is being torn down, simply
    add a NULL check in scsi_run_queue() to forestall this.
    
    Tested-by: Jim Schutt <jaschut@sandia.gov>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @hartkopp @gregkh

    can: add missing socket check in can/raw release

    hartkopp authored gregkh committed
    commit 10022a6 upstream.
    
    v2: added space after 'if' according code style.
    
    We can get here with a NULL socket argument passed from userspace,
    so we need to handle it accordingly.
    
    Thanks to Dave Jones pointing at this issue in net/can/bcm.c
    
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    drm/radeon/kms: add some new pci ids

    Alex Deucher authored gregkh committed
    commit e2c85d8 upstream.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    KVM: SVM: check for progress after IRET interception

    Avi Kivity authored gregkh committed
    commit bd3d1ec upstream.
    
    When we enable an NMI window, we ask for an IRET intercept, since
    the IRET re-enables NMIs.  However, the IRET intercept happens before
    the instruction executes, while the NMI window architecturally opens
    afterwards.
    
    To compensate for this mismatch, we only open the NMI window in the
    following exit, assuming that the IRET has by then executed; however,
    this assumption is not always correct; we may exit due to a host interrupt
    or page fault, without having executed the instruction.
    
    Fix by checking for forward progress by recording and comparing the IRET's
    rip.  This is somewhat of a hack, since an unchaging rip does not mean that
    no forward progress has been made, but is the simplest fix for now.
    
    Signed-off-by: Avi Kivity <avi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    cx88: Fix HVR4000 IR keymap

    Lawrence Rust authored gregkh committed
    [fixed in .39 in a much different way that is too big to backport to
    .38 - gregkh]
    
    Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in
    the 2.6.38 kernel.
    
    Signed-off-by: Lawrence Rust <lvr@softsystem.dot.uk>
    Acked-by: Jarod Wilson <jarod@wilsonet.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
  8. @gregkh

    fs/partitions/ldm.c: fix oops caused by corrupted partition table

    Timo Warns authored gregkh committed
    commit c340b1d upstream.
    
    The kernel automatically evaluates partition tables of storage devices.
    The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
    a bug that causes a kernel oops on certain corrupted LDM partitions.
    A kernel subsystem seems to crash, because, after the oops, the kernel no
    longer recognizes newly connected storage devices.
    
    The patch validates the value of vblk_size.
    
    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Timo Warns <warns@pre-sense.de>
    Cc: Eugene Teo <eugeneteo@kernel.sg>
    Cc: Harvey Harrison <harvey.harrison@gmail.com>
    Cc: Richard Russon <rich@flatcap.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @kernelslacker @gregkh

    can: Add missing socket check in can/bcm release.

    kernelslacker authored gregkh committed
    commit c6914a6 upstream.
    
    We can get here with a NULL socket argument passed from userspace,
    so we need to handle it accordingly.
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    Open with O_CREAT flag set fails to open existing files on non writab…

    Sachin Prabhu authored gregkh committed
    …le directories
    
    commit 1574dff upstream.
    
    An open on a NFS4 share using the O_CREAT flag on an existing file for
    which we have permissions to open but contained in a directory with no
    write permissions will fail with EACCES.
    
    A tcpdump shows that the client had set the open mode to UNCHECKED which
    indicates that the file should be created if it doesn't exist and
    encountering an existing flag is not an error. Since in this case the
    file exists and can be opened by the user, the NFS server is wrong in
    attempting to check create permissions on the parent directory.
    
    The patch adds a conditional statement to check for create permissions
    only if the file doesn't exist.
    
    Signed-off-by: Sachin S. Prabhu <sprabhu@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    XZ decompressor: Fix decoding of empty LZMA2 streams

    Lasse Collin authored gregkh committed
    commit 646032e upstream.
    
    The old code considered valid empty LZMA2 streams to be corrupt.
    Note that a typical empty .xz file has no LZMA2 data at all,
    and thus most .xz files having no uncompressed data are handled
    correctly even without this fix.
    
    Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    ARM: 6891/1: prevent heap corruption in OABI semtimedop

    Dan Rosenberg authored gregkh committed
    commit 0f22072 upstream.
    
    When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not
    bound the nsops argument.  A sufficiently large value will cause an
    integer overflow in allocation size, followed by copying too much data
    into the allocated buffer.  Fix this by restricting nsops to SEMOPM.
    Untested.
    
    Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @ebiederm @gregkh

    af_unix: Only allow recv on connected seqpacket sockets.

    ebiederm authored gregkh committed
    commit a05d2ad upstream.
    
    This fixes the following oops discovered by Dan Aloni:
    > Anyway, the following is the output of the Oops that I got on the
    > Ubuntu kernel on which I first detected the problem
    > (2.6.37-12-generic). The Oops that followed will be more useful, I
    > guess.
    
    >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
    > at           (null)
    > [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
    > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0
    > [ 5594.693720] Oops: 0002 [#1] SMP
    > [ 5594.699888] last sysfs file:
    
    The bug was that unix domain sockets use a pseduo packet for
    connecting and accept uses that psudo packet to get the socket.
    In the buggy seqpacket case we were allowing unconnected
    sockets to call recvmsg and try to receive the pseudo packet.
    
    That is always wrong and as of commit 7361c36 the pseudo
    packet had become enough different from a normal packet
    that the kernel started oopsing.
    
    Do for seqpacket_recv what was done for seqpacket_send in 2.5
    and only allow it on connected seqpacket sockets.
    
    Tested-by: Dan Aloni <dan@aloni.org>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @jmberg @gregkh

    mac80211: fix SMPS debugfs locking

    jmberg authored gregkh committed
    commit 243e6df upstream.
    
    The locking with SMPS requests means that the
    debugs file should lock the mgd mutex, not the
    iflist mutex. Calls to __ieee80211_request_smps()
    need to hold that mutex, so add an assertion.
    
    This has always been wrong, but for some reason
    never been noticed, probably because the locking
    error only happens while unassociated.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @nbd168 @gregkh

    ath9k: fix the return value of ath_stoprecv

    nbd168 authored gregkh committed
    commit 2232d31 upstream.
    
    The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
    a condition where rx DMA was stopped, but the MAC failed to enter the idle
    state. This condition requires a hardware reset, however the return value
    of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
    when issuing a fast channel change.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Reported-by: Paul Stewart <pstew@google.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors

    Boris Ostrovsky authored gregkh committed
    commit e20a2d2 upstream.
    
    Older AMD K8 processors (Revisions A-E) are affected by erratum
    400 (APIC timer interrupts don't occur in C states greater than
    C1). This, for example, means that X86_FEATURE_ARAT flag should
    not be set for these parts.
    
    This addresses regression introduced by commit
    b87cf80 ("x86, AMD: Set ARAT
    feature on AMD processors") where the system may become
    unresponsive until external interrupt (such as keyboard input)
    occurs. This results, for example, in time not being reported
    correctly, lack of progress on the system and other lockups.
    
    Reported-by: Joerg-Volker Peetz <jvpeetz@web.de>
    Tested-by: Joerg-Volker Peetz <jvpeetz@web.de>
    Acked-by: Borislav Petkov <borislav.petkov@amd.com>
    Signed-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
    Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @eparis @gregkh

    flex_arrays: allow zero length flex arrays

    eparis authored gregkh committed
    commit bf69d41 upstream.
    
    Just like kmalloc will allow one to allocate a 0 length segment of memory
    flex arrays should do the same thing.  It should bomb if you try to use
    something, but it should at least allow the allocation.
    
    This is needed because when SELinux switched to using flex_arrays in 2.6.38
    the inability to allocate a 0 length array resulted in SELinux policy load
    returning -ENOSPC when previously it worked.
    
    Based-on-patch-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Tested-by: Chris Richards <gizmo@giz-works.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @eparis @gregkh

    flex_array: flex_array_prealloc takes a number of elements, not an end

    eparis authored gregkh committed
    commit 5d30b10 upstream.
    
    Change flex_array_prealloc to take the number of elements for which space
    should be allocated instead of the last (inclusive) element. Users
    and documentation are updated accordingly.  flex_arrays got introduced before
    they had users.  When folks started using it, they ended up needing a
    different API than was coded up originally.  This swaps over to the API that
    folks apparently need.
    
    Based-on-patch-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Eric Paris <eparis@redhat.com>
    Tested-by: Chris Richards <gizmo@giz-works.com>
    Acked-by: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @jarodwilson @gregkh

    imon: add conditional locking in change_protocol

    jarodwilson authored gregkh committed
    commit 23ef710 upstream.
    
    The imon_ir_change_protocol function gets called two different ways, one
    way is from rc_register_device, for initial protocol selection/setup,
    and the other is via a userspace-initiated protocol change request,
    either by direct sysfs prodding or by something like ir-keytable.
    
    In the rc_register_device case, the imon context lock is already held,
    but when initiated from userspace, it is not, so we must acquire it,
    prior to calling send_packet, which requires that the lock is held.
    
    Without this change, there's an easily reproduceable deadlock when
    another function calls send_packet (such as either of the display write
    fops) after a userspace-initiated change_protocol.
    
    With a lock-debugging-enabled kernel, I was getting this:
    
    [   15.014153] =====================================
    [   15.015048] [ BUG: bad unlock balance detected! ]
    [   15.015048] -------------------------------------
    [   15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
    [   15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10
    [   15.015048] but there are no more locks to release!
    [   15.015048]
    [   15.015048] other info that might help us debug this:
    [   15.015048] 2 locks held by ir-keytable/773:
    [   15.015048]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144
    [   15.015048]  #1:  (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
    [   15.015048]
    [   15.015048] stack backtrace:
    [   15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
    [   15.015048] Call Trace:
    [   15.015048]  [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
    [   15.015048]  [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
    [   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
    [   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
    [   15.015048]  [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
    [   15.015048]  [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
    [   15.015048]  [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
    [   15.015048]  [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
    [   15.015048]  [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
    [   15.015048]  [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
    [   15.015048]  [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
    [   15.015048]  [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
    [   15.015048]  [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
    ...
    
    The original report that led to the investigation was the following:
    
    [ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
    [ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1 0x00000000
    [ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
    [ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
    [ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
    [ 1679.457319] Call Trace:
    [ 1679.457324]  [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
    [ 1679.457327]  [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
    [ 1679.457330]  [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
    [ 1679.457335]  [<ffffffff813b0c41>] mutex_lock+0x11/0x30
    [ 1679.457338]  [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
    [ 1679.457345]  [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
    [ 1679.457349]  [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
    [ 1679.457350]  [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
    [ 1679.457352]  [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
    ...
    
    Bump the driver version here so its easier to tell if people have this
    locking fix or not, and also make locking during probe easier to follow.
    
    Reported-by: Benjamin Hodgetts <ben@xnode.org>
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    v4l: make sure drivers supply a zeroed struct v4l2_subdev

    Herton Ronaldo Krzesinski authored gregkh committed
    commit 80845a3 upstream.
    
    Some v4l drivers currently don't initialize their struct v4l2_subdev
    with zeros, and this is a problem since some of the v4l2 code expects
    this. One example is the addition of internal_ops in commit 45f6f84,
    after that we are at risk of random oopses with these drivers when code
    in v4l2_device_register_subdev tries to dereference sd->internal_ops->*,
    as can be shown by the report at http://bugs.launchpad.net/bugs/745213
    and analysis of its crash at https://lkml.org/lkml/2011/4/1/168
    
    Use kzalloc within problematic drivers to ensure we have a zeroed struct
    v4l2_subdev.
    
    BugLink: http://bugs.launchpad.net/bugs/745213
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @dcbw @gregkh

    usbnet: add support for some Huawei modems with cdc-ether ports

    dcbw authored gregkh committed
    commit b3c914a upstream.
    
    Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
    compatible ports, so recognize and expose them.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    firewire: Fix for broken configrom updates in quick succession

    B.J. Buchalter authored gregkh committed
    commit 2e053a2 upstream.
    
    Current implementation of ohci_set_config_rom() uses a deferred
    bus reset via fw_schedule_bus_reset(). If clients add multiple
    unit descriptors to the config_rom in quick succession, the
    deferred bus reset may not have fired before succeeding update
    requests have come in. This can lead to an incorrect partial
    update of the config_rom for both addition and removal of
    config_rom descriptors, as the ohci_set_config_rom() routine
    will return -EBUSY if a previous pending update has not been
    completed yet; the requested update just gets dropped on the floor.
    
    This patch recognizes that the "in-flight" update can be modified
    until it has been processed by the bus-reset, and the locking
    in the bus_reset_tasklet ensures that the update is done atomically
    with respect to modifications made by ohci_set_config_rom(). The
    -EBUSY error case is simply removed.
    
    [Stefan R:  The bug always existed at least theoretically.  But it
    became easy to trigger since 2.6.36 commit 02d37be "firewire: core:
    integrate software-forced bus resets with bus management" which
    introduced long mandatory delays between janitorial bus resets.]
    
    Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    USB: fix regression in usbip by setting has_tt flag

    Alan Stern authored gregkh committed
    commit cee6a26 upstream.
    
    This patch (as1460) fixes a regression in the usbip driver caused by
    the new check for Transaction Translators in USB-2 hubs.  The root hub
    registered by vhci_hcd needs to have the has_tt flag set, because it
    can connect to low- and full-speed devices as well as high-speed
    devices.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    drm/radeon: fix regression on atom cards with hardcoded EDID record.

    Dave Airlie authored gregkh committed
    commit eaa4f5e upstream.
    
    Since fafcf94 introduced an edid size, it seems to have broken this path.
    
    This manifest as oops on T500 Lenovo laptops with dual graphics primarily.
    
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812
    
    Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @cjb @gregkh

    mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish

    cjb authored gregkh committed
    commit 0c9c99a upstream.
    
    It seems that under certain circumstances the sdhci_tasklet_finish()
    call can be entered with mrq set to NULL, causing the system to crash
    with a NULL pointer de-reference.
    
    Seen on S3C6410 system.  Based on a patch by Dimitris Papastamos.
    
    Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish

    Ben Dooks authored gregkh committed
    commit b7b4d34 upstream.
    
    It seems that under certain circumstances that the sdhci_tasklet_finish()
    call can be entered with mrq->cmd set to NULL, causing the system to crash
    with a NULL pointer de-reference.
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    PC is at sdhci_tasklet_finish+0x34/0xe8
    LR is at sdhci_tasklet_finish+0x24/0xe8
    
    Seen on S3C6410 system.
    
    Signed-off-by: Ben Dooks <ben-linux@fluff.org>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @cjb @gregkh

    mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()

    cjb authored gregkh committed
    commit 9fdcdbb upstream.
    
    If pci_ioremap_bar() fails during probe, we "goto release;" and free the
    host, but then we return 0 -- which tells sdhci_pci_probe() that the probe
    succeeded.  Since we think the probe succeeded, when we unload sdhci we'll
    go to sdhci_pci_remove_slot() and it will try to dereference slot->host,
    which is now NULL because we freed it in the error path earlier.
    
    The patch simply sets ret appropriately, so that sdhci_pci_probe() will
    detect the failure immediately and bail out.
    
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @lyakh @gregkh

    mmc: fix a race between card-detect rescan and clock-gate work instances

    lyakh authored gregkh committed
    commit 26fc877 upstream.
    
    Currently there is a race in the MMC core between a card-detect
    rescan work and the clock-gating work, scheduled from a command
    completion. Fix it by removing the dedicated clock-gating mutex
    and using the MMC standard locking mechanism instead.
    
    Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Cc: Simon Horman <horms@verge.net.au>
    Cc: Magnus Damm <damm@opensource.se>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @gregkh

    UBIFS: seek journal heads to the latest bud in replay

    Artem Bityutskiy authored gregkh committed
    commit 52c6e6f upstream.
    
    This is the second fix of the following symptom:
    
    UBIFS error (pid 34456): could not find an empty LEB
    
    which sometimes happens after power cuts when we mount the file-system - UBIFS
    refuses it with the above error message which comes from the
    'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test
    with the UBIFS power cut emulation enabled.
    
    Analysis of the problem.
    
    Currently UBIFS replay seeks the journal heads to the last _replayed_ bud.
    But the buds are replayed out-of-order, so the replay basically seeks journal
    heads to the "random" bud belonging to this head, and not to the _last_ one.
    
    The result of this is that the GC head may be seeked to a full LEB with no free
    space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a
    fully or mostly dirty LEB to match the current GC head (because we need to
    garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum).
    So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and
    also fail. As a result - recovery fails and mounting fails.
    
    This patch teaches the replay to initialize the GC heads exactly to the latest
    buds, i.e. the buds which have the largest sequence number in corresponding
    log reference nodes.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    UBIFS: do not free write-buffers when in R/O mode

    Artem Bityutskiy authored gregkh committed
    commit b50b9f4 upstream.
    
    Currently UBIFS has a small optimization - it frees write-buffers when it is
    re-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it
    does not allocate write-buffers as well.
    
    This optimization is nice but it leads to subtle problems and complications
    in recovery, which I can reproduce using the integck test. The symptoms are
    that after a power cut the file-system cannot be mounted if we first mount
    it R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints:
    
    UBIFS error (pid 34456): could not find an empty LEB
    
    Analysis of the  problem.
    
    When mounting R/W, the reply process sets journal heads to buds [1], but
    when mounting R/O - it does not do this, because the write-buffers are not
    allocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the
    same file-system but for the following 2 cases:
    
    1. mounting R/W after a power cut and recover
    2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery
    
    In the former case, we have journal heads seeked to the a bud, in the latter
    case, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not
    try to recover the GC LEB by garbage-collecting to the GC head, but we just
    try to find an empty LEB, and there may be no empty LEBs, so we just fail.
    On the other hand, in the former case (mount R/W), we are able to make a GC LEB
    (@c->gc_lnum) by garbage-collecting.
    
    Thus, let's remove this small nice optimization and always allocate
    write-buffers. This should not make too big difference - we have only 3
    of them, each of max. write unit size, which is usually 2KiB. So this is
    about 6KiB of RAM for the typical case, and only when mounted R/O.
    
    [1]: Note, currently the replay process is setting (seeking) the journal heads
    to _some_ buds, not necessarily to the buds which had been the journal heads
    before the power cut happened. This will be fixed separately.
    
    Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @rtg-tpi @gregkh

    atl1c: Fix work event interrupt/task races

    rtg-tpi authored gregkh committed
    commit cb77183 upstream.
    
    The mechanism used to initiate work events from the interrupt
    handler has a classic read/modify/write race between the interrupt
    handler that sets the condition, and the worker task that reads and
    clears the condition. Close these races by using atomic
    bit fields.
    
    Cc: Jie Yang <jie.yang@atheros.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @sgruszka @gregkh

    iwlagn: fix "Received BA when not expected"

    sgruszka authored gregkh committed
    commit bfd3610 upstream.
    
    Need to use broadcast sta_id for management frames, otherwise we broke
    BA session in the firmware and get messages like that:
    
    "Received BA when not expected"
    
    or (on older kernels):
    
    "BA scd_flow 0 does not match txq_id 10"
    
    This fix regression introduced in 2.6.35 during station management
    code rewrite by:
    
    commit 2a87c26
    Author: Johannes Berg <johannes.berg@intel.com>
    Date:   Fri Apr 30 11:30:45 2010 -0700
    
        iwlwifi: use iwl_find_station less
    
    Patch partially resolve:
    https://bugzilla.kernel.org/show_bug.cgi?id=16691
    However, there are still 11n performance problems on 4965 and 5xxx
    devices that need to be investigated.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @sgruszka @gregkh

    iwlwifi: fix skb usage after free

    sgruszka authored gregkh committed
    commit b250269 upstream.
    
    Since
    
    commit a120e91
    Author: Stanislaw Gruszka <sgruszka@redhat.com>
    Date:   Fri Feb 19 15:47:33 2010 -0800
    
        iwlwifi: sanity check before counting number of tfds can be free
    
    we use skb->data after calling ieee80211_tx_status_irqsafe(), which
    could free skb instantly.
    
    On current kernels I do not observe practical problems related with
    bug, but on 2.6.35.y it cause random system hangs when stressing
    wireless link.
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @gregkh

    workqueue: fix deadlock in worker_maybe_bind_and_lock()

    Tejun Heo authored gregkh committed
    commit 5035b20 upstream.
    
    If a rescuer and stop_machine() bringing down a CPU race with each
    other, they may deadlock on non-preemptive kernel.  The CPU won't
    accept a new task, so the rescuer can't migrate to the target CPU,
    while stop_machine() can't proceed because the rescuer is holding one
    of the CPU retrying migration.  GCWQ_DISASSOCIATED is never cleared
    and worker_maybe_bind_and_lock() retries indefinitely.
    
    This problem can be reproduced semi reliably while the system is
    entering suspend.
    
     http://thread.gmane.org/gmane.linux.kernel/1122051
    
    A lot of kudos to Thilo-Alexander for reporting this tricky issue and
    painstaking testing.
    
    stable: This affects all kernels with cmwq, so all kernels since and
            including v2.6.36 need this fix.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
    Tested-by: Thilo-Alexander Ginkel <thilo@ginkel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @gregkh

    i2c-parport: Fix adapter list handling

    Jean Delvare authored gregkh committed
    commit 56acc7a upstream.
    
    Use a standard list with proper locking to handle the list of
    adapters. Thankfully it only matters on systems with more than one
    parallel port, which are very rare.
    
    Thanks to Lukasz Kapiec for reporting the problem to me.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.