Commits on Mar 14, 2013
  1. Linux 3.4.36

    gregkh committed Mar 14, 2013
  2. USB: Fix connected device switch to Inactive state.

    [This is upstream commit d3b9d7a.
    It needs to be backported to kernels as old as 3.2, because it fixes the
    buggy commit 9dbcaec "USB: Handle warm
    reset failure on empty port."]
    A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit
    transition fails.  The current code in hub_events simply issues a warm
    reset, but does not call any pre-reset or post-reset driver methods (or
    unbind/rebind drivers without them).  Therefore the drivers won't know
    their device has just been reset.
    hub_events should instead call usb_reset_device.  This means
    hub_port_reset now needs to figure out whether it should issue a warm
    reset or a hot reset.
    Remove the FIXME note about needing disconnect() for a NOTATTACHED
    device.  This patch fixes that.
    Signed-off-by: Sarah Sharp <>
    Acked-by: Alan Stern <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sarah Sharp committed with gregkh Mar 13, 2013
  3. Revert "ALSA: hda - hdmi: Make jacks phantom, if they're not detectable"

    This reverts commit 30efd8d upstream
    (dd54ec4 in this tree) as it is not
    needed for the 3.4-stable tree.
    Cc: David Henningsson <>
    Cc: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    gregkh committed Mar 12, 2013
  4. USB: Rip out recursive call on warm port reset.

    [This is upstream commit 24a6078754f28528bc91e7e7b3e6ae86bd936d8.
    It needs to be backported to kernels as old as 3.2, because it fixes the
    buggy commit 9dbcaec "USB: Handle warm
    reset failure on empty port."]
    When a hot reset fails on a USB 3.0 port, the current port reset code
    recursively calls hub_port_reset inside hub_port_wait_reset.  This isn't
    ideal, since we should avoid recursive calls in the kernel, and it also
    doesn't allow us to issue multiple warm resets on reset failures.
    Rip out the recursive call.  Instead, add code to hub_port_reset to
    issue a warm reset if the hot reset fails, and try multiple warm resets
    before giving up on the port.
    In hub_port_wait_reset, remove the recursive call and re-indent.  The
    code is basically the same, except:
    1. It bails out early if the port has transitioned to Inactive or
    Compliance Mode after the reset completed.
    2. It doesn't consider a connect status change to be a failed reset.  If
    multiple warm resets needed to be issued, the connect status may have
    changed, so we need to ignore that and look at the port link state
    instead.  hub_port_reset will now do that.
    3. It unconditionally sets udev->speed on all types of successful
    resets.  The old recursive code would set the port speed when the second
    hub_port_reset returned.
    The old code did not handle connected devices needing a warm reset well.
    There were only two situations that the old code handled correctly: an
    empty port needing a warm reset, and a hot reset that migrated to a warm
    When an empty port needed a warm reset, hub_port_reset was called with
    the warm variable set.  The code in hub_port_finish_reset would skip
    telling the USB core and the xHC host that the device was reset, because
    otherwise that would result in a NULL pointer dereference.
    When a USB 3.0 device reset migrated to a warm reset, the recursive call
    made the call stack look like this:
    hub_port_reset(warm = false)
            hub_wait_port_reset(warm = false)
                    hub_port_reset(warm = true)
                            hub_wait_port_reset(warm = true)
                            hub_port_finish_reset(warm = true)
                            (return up the call stack to the first wait)
            hub_port_finish_reset(warm = false)
    The old code didn't want to notify the USB core or the xHC host of device reset
    twice, so it only did it in the second call to hub_port_finish_reset,
    when warm was set to false.  This was necessary because
    before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
    would pay attention to the xHC Reset Device command error status, and
    the second call would always fail.
    Now that we no longer have the recursive call, and warm can change from
    false to true in hub_port_reset, we need to have hub_port_finish_reset
    unconditionally notify the USB core and the xHC of the device reset.
    In hub_port_finish_reset, unconditionally clear the connect status
    change (CSC) bit for USB 3.0 hubs when the port reset is done.  If we
    had to issue multiple warm resets for a device, that bit may have been
    set if the device went into SS.Inactive and then was successfully warm
    Signed-off-by: Sarah Sharp <>
    Acked-by: Alan Stern <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sarah Sharp committed with gregkh Mar 8, 2013
  5. USB: Prepare for refactoring by adding extra udev checks.

    [This is upstream commit 2d4fa94.
    It needs to be backported to kernels as old as 3.2, because it fixes the
    buggy commit 9dbcaec "USB: Handle warm
    reset failure on empty port."]
    The next patch will refactor the hub port code to rip out the recursive
    call to hub_port_reset on a failed hot reset.  In preparation for that,
    make sure all code paths can deal with being called with a NULL udev.
    The usb_device will not be valid if warm reset was issued because a port
    transitioned to the Inactive or Compliance Mode on a device connect.
    This patch should have no effect on current behavior.
    Signed-off-by: Sarah Sharp <>
    Acked-by: Alan Stern <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sarah Sharp committed with gregkh Mar 8, 2013
  6. USB: Don't use EHCI port sempahore for USB 3.0 hubs.

    [This is upstream commit 0fe51aa.
    It needs to be backported to kernels as old as 3.2, because it fixes the
    buggy commit 9dbcaec "USB: Handle warm
    reset failure on empty port."]
    The EHCI host controller needs to prevent EHCI initialization when the
    UHCI or OHCI companion controller is in the middle of a port reset.  It
    uses ehci_cf_port_reset_rwsem to do this.  USB 3.0 hubs can't be under
    an EHCI host controller, so it makes no sense to down the semaphore for
    USB 3.0 hubs.  It also makes the warm port reset code more complex.
    Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs.
    Signed-off-by: Sarah Sharp <>
    Acked-by: Alan Stern <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sarah Sharp committed with gregkh Mar 8, 2013
  7. dmi_scan: fix missing check for _DMI_ signature in smbios_present()

    commit a40e7cf upstream.
    Commit 9f9c9cb ("drivers/firmware/dmi_scan.c: fetch dmi version
    from SMBIOS if it exists") hoisted the check for "_DMI_" into
    dmi_scan_machine(), which means that we don't bother to check for
    "_DMI_" at offset 16 in an SMBIOS entry.  smbios_present() may also call
    dmi_present() for an address where we found "_SM_", if it failed further
    Check for "_DMI_" in smbios_present() before calling dmi_present().
    [ fix build]
    Signed-off-by: Ben Hutchings <>
    Reported-by: Tim McGrath <>
    Tested-by: Tim Mcgrath <>
    Cc: Zhenzhong Duan <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    bwhacks committed with gregkh Mar 8, 2013
  8. ftrace: Update the kconfig for DYNAMIC_FTRACE

    commit db05021 upstream.
    The prompt to enable DYNAMIC_FTRACE (the ability to nop and
    enable function tracing at run time) had a confusing statement:
     "enable/disable ftrace tracepoints dynamically"
    This was written before tracepoints were added to the kernel,
    but now that tracepoints have been added, this is very confusing
    and has confused people enough to give wrong information during
    Not only that, I looked at the help text, and it still references
    that dreaded daemon that use to wake up once a second to update
    the nop locations and brick NICs, that hasn't been around for over
    five years.
    Time to bring the text up to the current decade.
    Reported-by: Ezequiel Garcia <>
    Signed-off-by: Steven Rostedt <>
    Signed-off-by: Greg Kroah-Hartman <>
    Steven Rostedt committed with gregkh Feb 28, 2013
  9. Fix memory leak in cpufreq stats.

    commit e377367 upstream.
    When system enters sleep, non-boot CPUs will be disabled.
    Cpufreq stats sysfs is created when the CPU is up, but it is not
    freed when the CPU is going down. This will cause memory leak.
    Signed-off-by: xiaobing tu <>
    Signed-off-by: guifang tang <>
    Signed-off-by: Rafael J. Wysocki <>
    Cc: Colin Cross <>
    Signed-off-by: Greg Kroah-Hartman <>
    tuxiaobing committed with gregkh Oct 22, 2012
  10. vfs: fix pipe counter breakage

    commit a930d87 upstream.
    If you open a pipe for neither read nor write, the pipe code will not
    add any usage counters to the pipe, causing the 'struct pipe_inode_info"
    to be potentially released early.
    That doesn't normally matter, since you cannot actually use the pipe,
    but the pipe release code - particularly fasync handling - still expects
    the actual pipe infrastructure to all be there.  And rather than adding
    NULL pointer checks, let's just disallow this case, the same way we
    already do for the named pipe ("fifo") case.
    This is ancient going back to pre-2.4 days, and until trinity, nobody
    naver noticed.
    Reported-by: Dave Jones <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Al Viro committed with gregkh Mar 12, 2013
  11. Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and…

    … security keys
    commit 8aec0f5 upstream.
    Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
    compat_process_vm_rw() shows that the compatibility code requires an
    explicit "access_ok()" check before calling
    compat_rw_copy_check_uvector(). The same difference seems to appear when
    we compare fs/read_write.c:do_readv_writev() to
    This subtle difference between the compat and non-compat requirements
    should probably be debated, as it seems to be error-prone. In fact,
    there are two others sites that use this function in the Linux kernel,
    and they both seem to get it wrong:
    Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
    also ends up calling compat_rw_copy_check_uvector() through
    aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
    be missing. Same situation for
    I propose that we add the access_ok() check directly into
    compat_rw_copy_check_uvector(), so callers don't have to worry about it,
    and it therefore makes the compat call code similar to its non-compat
    counterpart. Place the access_ok() check in the same location where
    copy_from_user() can trigger a -EFAULT error in the non-compat code, so
    the ABI behaviors are alike on both compat and non-compat.
    While we are here, fix compat_do_readv_writev() so it checks for
    compat_rw_copy_check_uvector() negative return values.
    And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
    Acked-by: Linus Torvalds <>
    Acked-by: Al Viro <>
    Signed-off-by: Mathieu Desnoyers <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    compudj committed with gregkh Feb 25, 2013
  12. keys: fix race with concurrent install_user_keyrings()

    commit 0da9dfd upstream.
    This fixes CVE-2013-1792.
    There is a race in install_user_keyrings() that can cause a NULL pointer
    dereference when called concurrently for the same user if the uid and
    uid-session keyrings are not yet created.  It might be possible for an
    unprivileged user to trigger this by calling keyctl() from userspace in
    parallel immediately after logging in.
    Assume that we have two threads both executing lookup_user_key(), both
    	===============================	===============================
    					==>call install_user_keyrings();
    	if (!cred->user->session_keyring)
    	==>call install_user_keyrings()
    					user->uid_keyring = uid_keyring;
    	if (user->uid_keyring)
    		return 0;
    	key = cred->user->session_keyring [== NULL]
    					user->session_keyring = session_keyring;
    	atomic_inc(&key->usage); [oops]
    At the point thread A dereferences cred->user->session_keyring, thread B
    hasn't updated user->session_keyring yet, but thread A assumes it is
    populated because install_user_keyrings() returned ok.
    The race window is really small but can be exploited if, for example,
    thread B is interrupted or preempted after initializing uid_keyring, but
    before doing setting session_keyring.
    This couldn't be reproduced on a stock kernel.  However, after placing
    systemtap probe on 'user->session_keyring = session_keyring;' that
    introduced some delay, the kernel could be crashed reliably.
    Fix this by checking both pointers before deciding whether to return.
    Alternatively, the test could be done away with entirely as it is checked
    inside the mutex - but since the mutex is global, that may not be the best
    Signed-off-by: David Howells <>
    Reported-by: Mateusz Guzik <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: James Morris <>
    Signed-off-by: Greg Kroah-Hartman <>
    dhowells committed with gregkh Mar 12, 2013
  13. crypto: user - fix info leaks in report API

    commit 9a5467b upstream.
    Three errors resulting in kernel memory disclosure:
    1/ The structures used for the netlink based crypto algorithm report API
    are located on the stack. As snprintf() does not fill the remainder of
    the buffer with null bytes, those stack bytes will be disclosed to users
    of the API. Switch to strncpy() to fix this.
    2/ crypto_report_one() does not initialize all field of struct
    crypto_user_alg. Fix this to fix the heap info leak.
    3/ For the module name we should copy only as many bytes as
    module_name() returns -- not as much as the destination buffer could
    hold. But the current code does not and therefore copies random data
    from behind the end of the module name, as the module name is always
    shorter than CRYPTO_MAX_ALG_NAME.
    Also switch to use strncpy() to copy the algorithm's name and
    driver_name. They are strings, after all.
    Signed-off-by: Mathias Krause <>
    Cc: Steffen Klassert <>
    Signed-off-by: Herbert Xu <>
    Signed-off-by: Greg Kroah-Hartman <>
    minipli committed with gregkh Feb 5, 2013
  14. xen/pat: Disable PAT using pat_enabled value.

    commit c79c498 upstream.
    The git commit 8eaffa6
    (xen/pat: Disable PAT support for now) explains in details why
    we want to disable PAT for right now. However that
    change was not enough and we should have also disabled
    the pat_enabled value. Otherwise we end up with:
    mmap-example:3481 map pfn expected mapping type write-back for
    [mem 0x00010000-0x00010fff], got uncached-minus
     ------------[ cut here ]------------
    WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0()
    mem 0x00010000-0x00010fff], got uncached-minus
    ------------[ cut here ]------------
    WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
    Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu
    Call Trace:
     [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
     [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
     [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
     [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
     [<ffffffff81157459>] unmap_vmas+0x49/0x90
     [<ffffffff8115f808>] exit_mmap+0x98/0x170
     [<ffffffff810559a4>] mmput+0x64/0x100
     [<ffffffff810560f5>] dup_mm+0x445/0x660
     [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
     [<ffffffff81057931>] do_fork+0x91/0x350
     [<ffffffff81057c76>] sys_clone+0x16/0x20
     [<ffffffff816ccbf9>] stub_clone+0x69/0x90
     [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
    ---[ end trace 4918cdd0a4c9fea4 ]---
    (a similar message shows up if you end up launching 'mcelog')
    The call chain is (as analyzed by Liu, Jinsong):
      --> copy_process
        --> dup_mm
          --> dup_mmap
           	--> copy_page_range
              --> track_pfn_copy
                --> reserve_pfn_range
                  --> line 624: flags != want_flags
    It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR
    Stefan Bader dug in this deep and found out that:
    "That makes it clearer as this will do
    --> pat_x_mtrr_type
      --> mtrr_type_lookup
        --> __mtrr_type_lookup
    And that can return -1/0xff in case of MTRR not being enabled/initialized. Which
    is not the case (given there are no messages for it in dmesg). This is not equal
    to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
    It looks like the problem starts early in reserve_memtype:
           	if (!pat_enabled) {
                    /* This is identical to page table setting without PAT */
                    if (new_type) {
                            if (req_type == _PAGE_CACHE_WC)
                                    *new_type = _PAGE_CACHE_UC_MINUS;
                                   	*new_type = req_type & _PAGE_CACHE_MASK;
                    return 0;
    This would be what we want, that is clearing the PWT and PCD flags from the
    supported flags - if pat_enabled is disabled."
    This patch does that - disabling PAT.
    Reported-by: Sander Eikelenboom <>
    Reported-and-Tested-by: Konrad Rzeszutek Wilk <>
    Reported-and-Tested-by: Stefan Bader <>
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Greg Kroah-Hartman <>
    Konrad Rzeszutek Wilk committed with gregkh Feb 26, 2013
  15. HID: logitech-dj: do not directly call hid_output_raw_report() during…

    … probe
    commit dcd9006 upstream.
    hid_output_raw_report() makes a direct call to usb_control_msg(). However,
    some USB3 boards have shown that the usb device is not ready during the
    .probe(). This blocks the entire usb device, and the paired mice, keyboards
    are not functional. The dmesg output is the following:
    [   11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
    [   11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32
    [   11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32
    Relying on the scheduled call to usbhid_submit_report() fixes the problem.
    related bugs:
    Reported-and-tested-by: Bob Bowles <>
    Signed-off-by: Benjamin Tissoires <>
    Signed-off-by: Jiri Kosina <>
    Signed-off-by: Greg Kroah-Hartman <>
    Benjamin Tissoires committed with gregkh Mar 5, 2013
  16. e1000e: fix pci-device enable-counter balance

    commit 4e0855d upstream.
    This patch removes redundant and unbalanced pci_disable_device() from
    __e1000_shutdown(). pci_clear_master() is enough, device can go into
    suspended state with elevated enable_cnt.
    Bug was introduced in commit 23606cf
    ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
    Signed-off-by: Konstantin Khlebnikov <>
    Cc: Bruce Allan <>
    Acked-by: Rafael J. Wysocki <>
    Tested-by: Borislav Petkov <>
    Tested-by: Aaron Brown <>
    Signed-off-by: Jeff Kirsher <>
    Signed-off-by: Greg Kroah-Hartman <>
    koct9i committed with gregkh Mar 5, 2013
  17. ALSA: vmaster: Fix slave change notification

    commit 2069d48 upstream.
    When a value of a vmaster slave control is changed, the ctl change
    notification is sometimes ignored.  This happens when the master
    control overrides, e.g. when the corresponding master control is
    muted.  The reason is that slave_put() returns the value of the actual
    slave put callback, and it doesn't reflect the virtual slave value
    This patch fixes the function just to return 1 whenever a slave value
    is changed.
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    tiwai committed with gregkh Mar 5, 2013
  18. ALSA: ice1712: Initialize card->private_data properly

    commit 69a4cfd upstream.
    Set card->private_data in snd_ice1712_create for fixing NULL
    dereference in snd_ice1712_remove().
    Signed-off-by: Sean Connor <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sean Connor committed with gregkh Feb 28, 2013
  19. ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit

    commit f2fe09b upstream.
    Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2,
    regardless of the settings in the HDCR.
    This patch fixes the broken mask.
    Reported-by: Christoffer Dall <>
    Signed-off-by: Will Deacon <>
    Signed-off-by: Russell King <>
    Signed-off-by: Greg Kroah-Hartman <>
    wildea01 committed with gregkh Feb 28, 2013
  20. drm/radeon: add primary dac adj quirk for R200 board

    commit e8fc413 upstream.
    vbios values are wrong leading to colors that are
    too bright.  Use the default values instead.
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alex Deucher committed with gregkh Feb 27, 2013
  21. hwmon: (pmbus/ltc2978) Use detected chip ID to select supported funct…

    commit f366fcc upstream.
    We read the chip ID from the chip, use it to determine if the chip ID provided
    to the driver is correct, and report it if wrong. We should also use the
    correct chip ID to select supported functionality.
    Signed-off-by: Guenter Roeck <>
    Acked-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    groeck committed with gregkh Feb 21, 2013
  22. hwmon: (pmbus/ltc2978) Fix peak attribute handling

    commit dbd712c upstream.
    Peak attributes were not initialized and cleared correctly.
    Also, temp2_max is only supported on page 0 and thus does not need to be
    an array.
    Signed-off-by: Guenter Roeck <>
    Acked-by: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    groeck committed with gregkh Feb 21, 2013
  23. hwmon: (sht15) Check return value of regulator_enable()

    commit 3e78080 upstream.
    Not having power is a pretty serious error so check that we are able to
    enable the supply and error out if we can't.
    Signed-off-by: Mark Brown <>
    Signed-off-by: Guenter Roeck <>
    broonie committed with gregkh Mar 2, 2013
  24. md: raid0: fix error return from create_stripe_zones.

    commit 58ebb34 upstream.
    Create_stripe_zones returns an error slightly differently to
    raid0_run and to raid0_takeover_*.
    The error returned used by the second was wrong and an error would
    result in mddev->private being set to NULL and sooner or later a
    So never return NULL, return ERR_PTR(err), not NULL from
    This bug has been present since 2.6.35 so the fix is suitable
    for any kernel since then.
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
    neilbrown committed with gregkh Feb 21, 2013
  25. md: fix two bugs when attempting to resize RAID0 array.

    commit a646853 upstream.
    You cannot resize a RAID0 array (in terms of making the devices
    bigger), but the code doesn't entirely stop you.
     disable setting of the available size on each device for
     RAID0 and Linear devices.  This must not change as doing so
     can change the effective layout of data.
     Make sure that the size that raid0_size() reports is accurate,
     but rounding devices sizes to chunk sizes.  As the device sizes
     cannot change now, this isn't so important, but it is best to be
    Without this change:
      mdadm --grow /dev/md0 -z max
      mdadm --grow /dev/md0 -Z max
      then read to the end of the array
    can cause a BUG in a RAID0 array.
    These bugs have been present ever since it became possible
    to resize any device, which is a long time.  So the fix is
    suitable for any -stable kerenl.
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
    neilbrown committed with gregkh Feb 21, 2013
  26. md: protect against crash upon fsync on ro array

    commit bbfa57c upstream.
    If an fsync occurs on a read-only array, we need to send a
    completion for the IO and may not increment the active IO count.
    Otherwise, we hit a bug trace and can't stop the MD array anymore.
    By advice of Christoph Hellwig we return success upon a flush
    request but we return -EROFS for other writes.
    We detect flush requests by checking if the bio has zero sectors.
    This patch is suitable to any -stable kernel to which it applies.
    Signed-off-by: Sebastian Riemer <>
    Cc: Christoph Hellwig <>
    Cc: Ben Hutchings <>
    Cc: NeilBrown <>
    Reported-by: Ben Hutchings <>
    Acked-by: Paul Menzel <>
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
    Sebastian Riemer committed with gregkh Feb 21, 2013
  27. ath9k_hw: improve reset reliability after errors

    commit 3412f2f upstream.
    On many different chips, important aspects of the MAC state are not
    fully cleared by a warm reset. This can show up as tx/rx hangs, those
    annoying "DMA failed to stop in 10 ms..." messages or other quirks.
    On AR933x, the chip can occasionally get stuck in a way that only a
    driver unload/reload or a reboot would bring it back to life.
    With this patch, a full reset is issued when bringing the chip out of
    FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
    properly. This makes the DMA related error messages disappear completely
    in my tests on AR933x, and the chip does not get stuck anymore.
    Signed-off-by: Felix Fietkau <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Felix Fietkau committed with gregkh Feb 25, 2013
  28. ath9k: fix RSSI dummy marker value

    commit a3d63ca upstream.
    RSSI is being stored internally as s8 in several places. The indication
    of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
    set to 127, but ended up being set to 0x127 because of a code cleanup
    mistake. This could lead to invalid signal strength values in a few
    Signed-off-by: Felix Fietkau <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Felix Fietkau committed with gregkh Feb 22, 2013
  29. mwifiex: correct sleep delay counter

    commit 3e7a4ff upstream.
    Maximum delay for waking up card is 50 ms. Because of typo in
    counter, this delay goes to 500ms. This patch fixes the bug.
    Signed-off-by: Avinash Patil <>
    Signed-off-by: Amitkumar Karwar <>
    Signed-off-by: Yogesh Ashok Powar <>
    Signed-off-by: Bing Zhao <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Avinash Patil committed with gregkh Feb 26, 2013
  30. hw_random: make buffer usable in scatterlist.

    commit f7f154f upstream.
    virtio_rng feeds the randomness buffer handed by the core directly
    into the scatterlist, since commit bb347d9.
    However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
    (at least on most archs).  We could fix this in virtio_rng, but it's actually
    far easier to just do it in the core as virtio_rng would have to allocate
    a buffer every time (it doesn't know how much the core will want to read).
    Reported-by: Aurelien Jarno <>
    Tested-by: Aurelien Jarno <>
    Signed-off-by: Rusty Russell <>
    Signed-off-by: Greg Kroah-Hartman <>
    rustyrussell committed with gregkh Mar 4, 2013
  31. ata_piix: reenable MS Virtual PC guests

    commit d990434 upstream.
    An earlier commit cd00608 ("ata_piix:
    defer disks to the Hyper-V drivers by default") broke MS Virtual PC
    guests. Hyper-V guests and Virtual PC guests have nearly identical DMI
    info. As a result the driver does currently ignore the emulated hardware
    in Virtual PC guests and defers the handling to hv_blkvsc. Since Virtual
    PC does not offer paravirtualized drivers no disks will be found in the
    One difference in the DMI info is the product version. This patch adds a
    match for MS Virtual PC 2007 and "unignores" the emulated hardware.
    This was reported for openSuSE 12.1 in bugzilla:
    Here is a detailed list of DMI info from example guests:
    hwinfo --bios:
    virtual pc guest:
      System Info: #1
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "VS2005R2"
        Serial: "3178-9905-1533-4840-9282-0569-59"
        UUID: undefined, but settable
        Wake-up: 0x06 (Power Switch)
      Board Info: #2
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "5.0"
        Serial: "3178-9905-1533-4840-9282-0569-59"
      Chassis Info: #3
        Manufacturer: "Microsoft Corporation"
        Version: "5.0"
        Serial: "3178-9905-1533-4840-9282-0569-59"
        Asset Tag: "7188-3705-6309-9738-9645-0364-00"
        Type: 0x03 (Desktop)
        Bootup State: 0x03 (Safe)
        Power Supply State: 0x03 (Safe)
        Thermal State: 0x01 (Other)
        Security Status: 0x01 (Other)
    win2k8 guest:
      System Info: #1
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "7.0"
        Serial: "9106-3420-9819-5495-1514-2075-48"
        UUID: undefined, but settable
        Wake-up: 0x06 (Power Switch)
      Board Info: #2
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "7.0"
        Serial: "9106-3420-9819-5495-1514-2075-48"
      Chassis Info: #3
        Manufacturer: "Microsoft Corporation"
        Version: "7.0"
        Serial: "9106-3420-9819-5495-1514-2075-48"
        Asset Tag: "7076-9522-6699-1042-9501-1785-77"
        Type: 0x03 (Desktop)
        Bootup State: 0x03 (Safe)
        Power Supply State: 0x03 (Safe)
        Thermal State: 0x01 (Other)
        Security Status: 0x01 (Other)
    win2k12 guest:
      System Info: #1
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "7.0"
        Serial: "8179-1954-0187-0085-3868-2270-14"
        UUID: undefined, but settable
        Wake-up: 0x06 (Power Switch)
      Board Info: #2
        Manufacturer: "Microsoft Corporation"
        Product: "Virtual Machine"
        Version: "7.0"
        Serial: "8179-1954-0187-0085-3868-2270-14"
      Chassis Info: #3
        Manufacturer: "Microsoft Corporation"
        Version: "7.0"
        Serial: "8179-1954-0187-0085-3868-2270-14"
        Asset Tag: "8374-0485-4557-6331-0620-5845-25"
        Type: 0x03 (Desktop)
        Bootup State: 0x03 (Safe)
        Power Supply State: 0x03 (Safe)
        Thermal State: 0x01 (Other)
        Security Status: 0x01 (Other)
    Signed-off-by: Olaf Hering <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Greg Kroah-Hartman <>
    olafhering committed with gregkh Sep 18, 2012
  32. SUNRPC: Don't start the retransmission timer when out of socket space

    commit a9a6b52 upstream.
    If the socket is full, we're better off just waiting until it empties,
    or until the connection is broken. The reason why we generally don't
    want to time out is that the call to xprt->ops->release_xprt() will
    trigger a connection reset, which isn't helpful...
    Let's make an exception for soft RPC calls, since they have to provide
    timeout guarantees.
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
    Trond Myklebust committed with gregkh Feb 22, 2013
  33. NFS: Don't allow NFS silly-renamed files to be deleted, no signal

    commit 5a7a613 upstream.
    Commit 73ca100 broke the code that prevents the client from deleting
    a silly renamed dentry.  This affected "delete on last close"
    semantics as after that commit, nothing prevented removal of
    silly-renamed files.  As a result, a process holding a file open
    could easily get an ESTALE on the file in a directory where some
    other process issued 'rm -rf some_dir_containing_the_file' twice.
    Before the commit, any attempt at unlinking silly renamed files would
    fail inside may_delete() with -EBUSY because of the
    DCACHE_NFSFS_RENAMED flag.  The following testcase demonstrates
    the problem:
      tail -f /nfsmnt/dir/file &
      rm -rf /nfsmnt/dir
      rm -rf /nfsmnt/dir
      # second removal does not fail, 'tail' process receives ESTALE
    The problem with the above commit is that it unhashes the old and
    new dentries from the lookup path, even in the normal case when
    a signal is not encountered and it would have been safe to call
    d_move.  Unfortunately the old dentry has the special
    DCACHE_NFSFS_RENAMED flag set on it.  Unhashing has the
    side-effect that future lookups call d_alloc(), allocating a new
    dentry without the special flag for any silly-renamed files.  As a
    result, subsequent calls to unlink silly renamed files do not fail
    but allow the removal to go through.  This will result in ESTALE
    errors for any other process doing operations on the file.
    To fix this, go back to using d_move on success.
    For the signal case, it's unclear what we may safely do beyond d_drop.
    Reported-by: Dave Wysochanski <>
    Signed-off-by: Trond Myklebust <>
    Acked-by: Jeff Layton <>
    Signed-off-by: Greg Kroah-Hartman <>
    Trond Myklebust committed with gregkh Feb 22, 2013
  34. cifs: ensure that cifs_get_root() only traverses directories

    commit ce2ac52 upstream.
    Kjell Braden reported this oops:
    [  833.211970] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  833.212816] IP: [<          (null)>]           (null)
    [  833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
    [  833.213874] Oops: 0010 [#1] SMP
    [  833.214344] CPU 0
    [  833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000
    [  833.215629]
    [  833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox
    [  833.215629] RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
    [  833.215629] RSP: 0018:ffff8800119c9c50  EFLAGS: 00010282
    [  833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000
    [  833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8
    [  833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7
    [  833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8
    [  833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6
    [  833.215629] FS:  00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
    [  833.215629] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [  833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0
    [  833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [  833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)
    [  833.215629] Stack:
    [  833.215629]  ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286
    [  833.215629]  0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8
    [  833.215629]  ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0
    [  833.215629] Call Trace:
    [  833.215629]  [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90
    [  833.215629]  [<ffffffff81178075>] ? d_lookup+0x35/0x60
    [  833.215629]  [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0
    [  833.215629]  [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0
    [  833.215629]  [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20
    [  833.215629]  [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]
    [  833.215629]  [<ffffffff81163bd3>] mount_fs+0x43/0x1b0
    [  833.215629]  [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0
    [  833.215629]  [<ffffffff8117e584>] do_kern_mount+0x54/0x110
    [  833.215629]  [<ffffffff8117fdc2>] do_mount+0x262/0x840
    [  833.215629]  [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50
    [  833.215629]  [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180
    [  833.215629]  [<ffffffff8118075d>] sys_mount+0x8d/0xe0
    [  833.215629]  [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b
    [  833.215629] Code:  Bad RIP value.
    [  833.215629] RIP  [<          (null)>]           (null)
    [  833.215629]  RSP <ffff8800119c9c50>
    [  833.215629] CR2: 0000000000000000
    [  833.238525] ---[ end trace ec00758b8d44f529 ]---
    When walking down the path on the server, it's possible to hit a
    symlink. The path walking code assumes that the caller will handle that
    situation properly, but cifs_get_root() isn't set up for it. This patch
    prevents the oops by simply returning an error.
    A better solution would be to try and chase the symlinks here, but that's
    fairly complicated to handle.
    Reported-and-tested-by: Kjell Braden <>
    Signed-off-by: Jeff Layton <>
    Signed-off-by: Steve French <>
    Signed-off-by: Greg Kroah-Hartman <>
    jtlayton committed with gregkh Feb 1, 2013
  35. btrfs: Init io_lock after cloning btrfs device struct

    commit 1cba0cd upstream.
    __btrfs_close_devices() clones btrfs device structs with
    memcpy(). Some of the fields in the clone are reinitialized, but it's
    missing to init io_lock. In mainline this goes unnoticed, but on RT it
    leaves the plist pointing to the original about to be freed lock
    Initialize io_lock after cloning, so no references to the original
    struct are left.
    Reported-and-tested-by: Mike Galbraith <>
    Signed-off-by: Thomas Gleixner <>
    Signed-off-by: Chris Mason <>
    Signed-off-by: Greg Kroah-Hartman <>
    Thomas Gleixner committed with gregkh Feb 20, 2013