07 Dec, 2014

40 commits

  • Greg Kroah-Hartman
     
  • commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187 upstream.

    After removal of the central spinlock nf_conntrack_lock, in
    commit 93bb0ceb75be2 ("netfilter: conntrack: remove central
    spinlock nf_conntrack_lock"), it is possible to race against
    get_next_corpse().

    The race is against the get_next_corpse() cleanup on
    the "unconfirmed" list (a per-cpu list with seperate locking),
    which set the DYING bit.

    Fix this race, in __nf_conntrack_confirm(), by removing the CT
    from unconfirmed list before checking the DYING bit. In case
    race occured, re-add the CT to the dying list.

    While at this, fix coding style of the comment that has been
    updated.

    Fixes: 93bb0ceb75be2 ("netfilter: conntrack: remove central spinlock nf_conntrack_lock")
    Reported-by: bill bonaparte
    Signed-off-by: bill bonaparte
    Signed-off-by: Jesper Dangaard Brouer
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Greg Kroah-Hartman

    bill bonaparte
     
  • commit c1118b3602c2329671ad5ec8bdf8e374323d6343 upstream.

    On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA.
    In that case, KVM will fail to patch VMCALL instructions to VMMCALL
    as required on AMD processors.

    The failure mode is currently a divide-by-zero exception, which obviously
    is a KVM bug that has to be fixed. However, picking the right instruction
    between VMCALL and VMMCALL will be faster and will help if you cannot upgrade
    the hypervisor.

    Reported-by: Chris Webb
    Tested-by: Chris Webb
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: "H. Peter Anvin"
    Cc: x86@kernel.org
    Acked-by: Borislav Petkov
    Signed-off-by: Paolo Bonzini
    Cc: Chris J Arges
    Signed-off-by: Greg Kroah-Hartman

    Paolo Bonzini
     
  • commit 9a6cb70f40b0268297024949eb0a2689e3b7769b upstream.

    There is a duplication in a clock name for apq8084 platform that causes
    the following warning: "RBCPR_CLK_SRC" redefined

    Resolve this by adding a MMSS_ prefix to this clock and making its name
    coherent with msm8974 platform.

    Fixes: 2b46cd23a5a2 ("clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support")
    Signed-off-by: Georgi Djakov
    Reviewed-by: Stephen Boyd
    Signed-off-by: Michael Turquette
    Signed-off-by: Greg Kroah-Hartman

    Georgi Djakov
     
  • original upstream id: 7a7f84ccb82e542c845c43f604665ccea1247866

    Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
    to handle hpd we would need to turn on vdd to perform aux transfers.
    This would lead to an endless cycle of
    "vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."

    So ignore long hpd pulses on eDP ports. eDP panels should be physically
    tied to the machine anyway so they should not actually disappear and
    thus don't need long hpd handling. Short hpds are still needed for link
    re-train and whatnot so we can't just turn off the hpd interrupt
    entirely for eDP ports. Perhaps we could turn it off whenever the panel
    is disabled, but just ignoring the long hpd seems sufficient.

    Signed-off-by: Ville Syrjälä
    Reviewed-by: Dave Airlie
    Reviewed-by: Todd Previte
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Ville Syrjälä
     
  • commit 5ac6c72e594471acfa5b00210c51d533a73413ad upstream.

    Older firmwares do not provide support for the HOT_SPOT_CMD command.
    Check for the appropriate TLV flag that declares hotspot support in
    the firmware to prevent a firmware assertion failure that can be
    triggered from the userspace,

    Signed-off-by: Luciano Coelho
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Greg Kroah-Hartman

    Luciano Coelho
     
  • commit a6cc5163149532734b84c86cbffa4994e527074b upstream.

    Don't add the time event to the list. We added it several
    times the same time event, which leads to an infinite loop
    when walking the list.

    Since we (currently) don't support more than one ROC for STA
    vif at a time, enforce this and don't add the time event
    to any list.

    We were also missing the locking of the mutex which led to
    a lockdep splat - fix that.

    Signed-off-by: Matti Gottlieb
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Greg Kroah-Hartman

    Matti Gottlieb
     
  • commit 360743814c4082515581aa23ab1d8e699e1fbe88 upstream.

    Instead of the arch specific quirk which we are deprecating
    and that drivers don't understand.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit 00b4d9a14125f1e51874def2b9de6092e007412d upstream.

    On some 32 bits architectures, including x86, GENMASK(31, 0) returns 0
    instead of the expected ~0UL.

    This is the same on some 64 bits architectures with GENMASK_ULL(63, 0).

    This is due to an overflow in the shift operand, 1 << 32 for GENMASK,
    1 << 64 for GENMASK_ULL.

    Reported-by: Eric Paire
    Suggested-by: Rasmus Villemoes
    Signed-off-by: Maxime Coquelin
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: linux@rasmusvillemoes.dk
    Cc: gong.chen@linux.intel.com
    Cc: John Sullivan
    Cc: Linus Torvalds
    Cc: Paul E. McKenney
    Cc: Theodore Ts'o
    Fixes: 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK macro")
    Link: http://lkml.kernel.org/r/1415267659-10563-1-git-send-email-maxime.coquelin@st.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Maxime COQUELIN
     
  • commit 83d04c39f9048807a8500e575ae3f1718a3f45bb upstream.

    Fixes kfree of the sadb buffer when it's NULL.

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit 91ed6fd2c383bb8f02d66e98b4a4d2f7207249dc upstream.

    Some radeon ASICs don't support all 64 address bits of MSIs despite
    advertising support for 64-bit MSIs in their configuration space.

    This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
    be assigned with some of the high address bits set.

    This makes use of the newly introduced "no_64bit_msi" flag in structure
    pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
    on those adapters.

    Adding Alex's review tag. Patch to the driver is identical to the
    reviewed one, I dropped the arch/powerpc hunk rewrote the subject
    and cset comment.

    Signed-off-by: Benjamin Herrenschmidt
    Reviewed-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit 1348579433566355e570008929daa09a0db64fd8 upstream.

    If ddc fails, presumably the i2c mux (and hopefully the signal
    mux) are switched to the other GPU so don't fetch the edid from
    the vbios so that the connector reports disconnected.

    bug:
    https://bugzilla.opensuse.org/show_bug.cgi?id=904417

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit bdfa7542d40e6251c232a802231b37116bd31b11 upstream.

    During a GPU reset we need to get pending page flip cleared out
    since the ring contents are gone and flip will never complete
    on its own. This used to work until the mmio vs. CS flip race
    detection came about. That piece of code is looking for a
    specific surface address in the SURFLIVE register, but as
    a flip to that address may never happen the check may never
    pass. So we should just skip the SURFLIVE and flip counter
    checks when the GPU gets reset.

    intel_display_handle_reset() tries to effectively complete
    the flip anyway by calling .update_primary_plane(). But that
    may not satisfy the conditions of the mmio vs. CS race
    detection since there's no guarantee that a modeset didn't
    sneak in between the GPU reset and intel_display_handle_reset().
    Such a modeset will not wait for pending flips due to the ongoing GPU
    reset, and then the primary plane updates performed by
    intel_display_handle_reset() will already use the new surface
    address, and thus the surface address the flip is waiting for
    might never appear in SURFLIVE. The result is that the flip
    will never complete and attempts to perform further page flips
    will fail with -EBUSY.

    During the GPU reset intel_crtc_has_pending_flip() will return
    false regardless, so the deadlock with a modeset vs. the error
    work acquiring crtc->mutex was avoided. And the reset_counter
    check in intel_crtc_has_pending_flip() actually made this bug
    even less severe since it allowed normal modesets to go through
    even though there's a pending flip.

    This is a regression introduced by me here:
    commit 75f7f3ec600524c9544cc31695155f1a9ddbe1d9
    Author: Ville Syrjälä
    Date: Tue Apr 15 21:41:34 2014 +0300

    drm/i915: Fix mmio vs. CS flip race on ILK+

    Testcase: igt/kms_flip/flip-vs-panning-vs-hang
    Signed-off-by: Ville Syrjälä
    Reviewed-by: Chris Wilson
    Reviewed-by: Daniel Vetter
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Ville Syrjälä
     
  • commit 0485c9dc24ec0939b42ca5104c0373297506b555 upstream.

    It's magic, but it seems to work.

    This fixes a regression introduced in

    commit 1bb9e632a0aeee1121e652ee4dc80e5e6f14bcd2
    Author: Daniel Vetter
    Date: Tue Jul 8 10:02:43 2014 +0200

    drm/i915: Only unbind vgacon, not other console drivers

    My best guess is that the vga fbdev driver falls over if we rip out
    parts of vgacon. Hooray.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
    Reported-and-tested-by: Lv Zheng
    Signed-off-by: Daniel Vetter
    Acked-by: Chris Wilson
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Daniel Vetter
     
  • commit 2208d655a91f9879bd9a39ff9df05dd668b3512c upstream.

    This reverts the regressing

    commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f
    Author: Daniel Vetter
    Date: Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch

    that causes GPU hangs immediately on boot.

    Reported-by: Leo Wolf
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
    Signed-off-by: Daniel Vetter
    [Jani: amended the commit message slightly.]
    Signed-off-by: Jani Nikula
    Signed-off-by: Greg Kroah-Hartman

    Daniel Vetter
     
  • commit b7bc596ebbe0cddc97d76ef9309f64471bbf13eb upstream.

    Just use the acpi interface. That's what windows uses on this
    generation and it's the only thing that seems to work reliably
    on these generation parts.

    You can still force the native backlight interface by setting
    radeon.backlight=1

    Bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=88501

    v2: merge into above if/else block

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit 28731d5818ae25b92d1fb82fe0ac196e97102c1b upstream.

    Value needs to be swapped on BE.

    Signed-off-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Alex Deucher
     
  • commit e6d5e7d90be92cee626d7ec16ca9b06f1eed710b upstream.

    Commit 79c6ab509558 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in
    v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the
    recalc_rate() and round_rate() clock callbacks to be omitted.

    However using this flag has the unfortunate side effect of causing the
    clock recalculation code when a clock rate change is attempted to always
    treat it as a pass-through clock, i.e. with a fixed divide of 1, which
    may not be the case. Child clock rates are then recalculated using the
    wrong parent rate.

    Therefore instead of dropping the recalc_rate() and round_rate()
    callbacks, alter clk_divider_bestdiv() to always report the current
    divider as the best divider so that it is never altered.

    For me the read only clock was the system clock, which divided the PLL
    rate by 2, from which both the UART and the SPI clocks were divided.
    Initial setting of the UART rate set it correctly, but when the SPI
    clock was set, the other child clocks were miscalculated. The UART clock
    was recalculated using the PLL rate as the parent rate, resulting in a
    UART new_rate of double what it should be, and a UART which spewed forth
    garbage when the rate changes were propagated.

    Signed-off-by: James Hogan
    Cc: Thomas Abraham
    Cc: Tomasz Figa
    Cc: Max Schwarz
    Acked-by: Haojian Zhuang
    Signed-off-by: Michael Turquette
    Signed-off-by: Greg Kroah-Hartman

    James Hogan
     
  • commit 01a4cc4d0cd6a836c7b923760e8eb1cbb6a47258 upstream.

    In some cases, the fcoe_rx_list may contains multiple instances
    of the same skb (the so called "shared skbs").

    the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
    modifies (and destroys) its content and then proceed to the next one.
    The problem is that if the skb is shared, the remaining instances will
    be corrupted.

    The solution is to use skb_share_check() before adding the skb to the
    fcoe_rx_list.

    [ 6286.808725] ------------[ cut here ]------------
    [ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
    [ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
    [ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 3.10.0-121.el7.x86_64 #1
    [ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
    [ 6286.808752] 0000000000000000 000000000b36e715 ffff8800deba1e00 ffffffff815ec0ba
    [ 6286.808753] ffff8800deba1e38 ffffffff8105dee1 ffffffffa05618c0 ffff8801e4c81888
    [ 6286.808754] ffffe8ffff663868 ffff8801f402b180 ffff8801f56bc000 ffff8800deba1e48
    [ 6286.808754] Call Trace:
    [ 6286.808759] [] dump_stack+0x19/0x1b
    [ 6286.808762] [] warn_slowpath_common+0x61/0x80
    [ 6286.808763] [] warn_slowpath_null+0x1a/0x20
    [ 6286.808765] [] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
    [ 6286.808767] [] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
    [ 6286.808769] [] kthread+0xcf/0xe0
    [ 6286.808770] [] ? kthread_create_on_node+0x140/0x140
    [ 6286.808772] [] ret_from_fork+0x7c/0xb0
    [ 6286.808773] [] ? kthread_create_on_node+0x140/0x140
    [ 6286.808774] ---[ end trace c6cdb939184ccb4e ]---

    Signed-off-by: Maurizio Lombardi
    Acked-by: Chad Dupuis
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Greg Kroah-Hartman

    Maurizio Lombardi
     
  • commit 45977fe35bf014f5cf9552717e1320783398ae0d upstream.

    First of all IRQCHIP_SKIP_SET_WAKE is not a valid irq_gc_flags and thus
    should not be passed as the last argument of
    irq_alloc_domain_generic_chips.

    Then pass the correct handler (handle_fasteoi_irq) to
    irq_alloc_domain_generic_chips instead of manually re-setting it in the
    initialization loop.

    And eventually initialize default irq flags to the pseudo standard:
    IRQ_REQUEST | IRQ_PROBE | IRQ_AUTOEN.

    Signed-off-by: Boris Brezillon
    Tested-by: Kevin Hilman
    Fixes: b1479ebb77200 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers")
    Link: https://lkml.kernel.org/r/1415712816-9202-1-git-send-email-boris.brezillon@free-electrons.com
    Signed-off-by: Jason Cooper
    Signed-off-by: Greg Kroah-Hartman

    Boris Brezillon
     
  • commit b5b2ffc0574e1f271d79b6b992ee382dc9d5eaa8 upstream.

    While working on a different issue, I noticed an annoying use
    after free bug on my machine when unloading the ixgbe driver:

    [ 8642.318797] ixgbe 0000:02:00.1: removed PHC on p2p2
    [ 8642.742716] ixgbe 0000:02:00.1: complete
    [ 8642.743784] BUG: unable to handle kernel paging request at ffff8807d3740a90
    [ 8642.744828] IP: [] ixgbe_remove+0xfc/0x1b0 [ixgbe]
    [ 8642.745886] PGD 20c6067 PUD 81c1f6067 PMD 81c15a067 PTE 80000007d3740060
    [ 8642.746956] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [ 8642.748039] Modules linked in: [...]
    [ 8642.752929] CPU: 1 PID: 1225 Comm: rmmod Not tainted 3.18.0-rc2+ #49
    [ 8642.754203] Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 1.1b 11/01/2013
    [ 8642.755505] task: ffff8807e34d3fe0 ti: ffff8807b7204000 task.ti: ffff8807b7204000
    [ 8642.756831] RIP: 0010:[] [] ixgbe_remove+0xfc/0x1b0 [ixgbe]
    [...]
    [ 8642.774335] Stack:
    [ 8642.775805] ffff8807ee824098 ffff8807ee824098 ffffffffa01f3000 ffff8807ee824000
    [ 8642.777326] ffff8807b7207e18 ffffffff8137720f ffff8807ee824098 ffff8807ee824098
    [ 8642.778848] ffffffffa01f3068 ffff8807ee8240f8 ffff8807b7207e38 ffffffff8144180f
    [ 8642.780365] Call Trace:
    [ 8642.781869] [] pci_device_remove+0x3f/0xc0
    [ 8642.783395] [] __device_release_driver+0x7f/0xf0
    [ 8642.784876] [] driver_detach+0xb8/0xc0
    [ 8642.786352] [] bus_remove_driver+0x59/0xe0
    [ 8642.787783] [] driver_unregister+0x30/0x70
    [ 8642.789202] [] pci_unregister_driver+0x25/0xa0
    [ 8642.790657] [] ixgbe_exit_module+0x1c/0xc8e [ixgbe]
    [ 8642.792064] [] SyS_delete_module+0x132/0x1c0
    [ 8642.793450] [] ? do_notify_resume+0x61/0xa0
    [ 8642.794837] [] system_call_fastpath+0x12/0x17

    The issue is that test_and_set_bit() done on adapter->state is being
    performed *after* the netdevice has been freed via free_netdev().

    When netdev is being allocated on initialization time, it allocates
    a private area, here struct ixgbe_adapter, that resides after the
    net_device structure. In ixgbe_probe(), the device init routine,
    we set up the adapter after alloc_etherdev_mq() on the private area
    and add a reference for the pci_dev as well via pci_set_drvdata().

    Both in the error path of ixgbe_probe(), but also on module unload
    when ixgbe_remove() is being called, commit 41c62843eb6a ("ixgbe:
    Fix rcu warnings induced by LER") accesses adapter after free_netdev().
    The patch stores the result in a bool and thus fixes above oops on my
    side.

    Fixes: 41c62843eb6a ("ixgbe: Fix rcu warnings induced by LER")
    Cc: Mark Rustad
    Signed-off-by: Daniel Borkmann
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Daniel Borkmann
     
  • commit 4556dc591691fca743518edb24f15fbc83b5c8ef upstream.

    IXGBE adapter seems to require that VLAN filtering be enabled if
    VMDQ or SRIOV are enabled. When those functions are disabled,
    VLAN filtering may be disabled in promiscuous mode.

    Prior to commit a9b8943ee129 ("ixgbe: remove vlan_filter_disable
    and enable functions")

    The logic was correct. However, after the commit the logic
    got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
    is disabled.

    This patch changes the condition to enable hw vlan filtered
    when VMDQ or SRIOV is enabled.

    Fixes: a9b8943ee129 ("ixgbe: remove vlan_filter_disable and enable functions")
    CC: Jacob Keller
    Signed-off-by: Vladislav Yasevich
    Acked-by: Emil Tantilov
    Tested-by: Phil Schmitt
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Vlad Yasevich
     
  • commit 9b41ebd3cf0f68d8cad779d3eeba336f78262e43 upstream.

    commit ff8cbf250b44 ("xhci: clear root port wake on bits if controller isn't")
    can cause device detection error if runtime PM is enabled, and S3 wake
    is disabled. Revert it.
    https://bugzilla.kernel.org/show_bug.cgi?id=85701

    This commit got into stable and should be reverted from there as well.

    Signed-off-by: Lu Baolu
    Reported-by: Dmitry Nezhevenko
    [Mathias Nyman: reword commit message]
    Signed-off-by: Mathias Nyman
    Signed-off-by: Greg Kroah-Hartman

    Lu Baolu
     
  • commit 91a0b603469069cdcce4d572b7525ffc9fd352a6 upstream.

    ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
    dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
    sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
    sock will be returned.
    the fix is to "continue" the searching, if no matching, return NULL.

    Cc: "David S. Miller"
    Cc: Alexey Kuznetsov
    Cc: James Morris
    Cc: Hideaki YOSHIFUJI
    Cc: Patrick McHardy
    Cc: netdev@vger.kernel.org
    Signed-off-by: Jane Zhou
    Signed-off-by: Yiwei Zhao
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Jane Zhou
     
  • commit 6b19b66013cfe608d63f0dab38834bbaceb0217a upstream.

    g762_remove() needs to first call hwmon_device_unregister() and then
    g762_of_clock_disable(). For that reason, it is not possible to
    convert it to devm_hwmon_device_register_with_groups() and the
    the non device managed version must be used.

    This is correctly stated in commit message for 398e16db6262 ("hwmon:
    (g762) Convert to hwmon_device_register_with_groups") but the
    associated changes do in fact introduce a call to the device managed
    version of the function.

    This patch fixes that typo by switching to the non devm_ version.

    Fixes: 398e16db6262 ("hwmon: (g762) Convert to hwmon_device_register_with_groups")
    Signed-off-by: Arnaud Ebalard
    Signed-off-by: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Arnaud Ebalard
     
  • commit db79afa1e57925ba96ab18514c0ebe42a28e393e upstream.

    A number of radeon cards have a HW limitation causing them to be
    unable to generate the full 64-bit of address bits for MSIs. This
    breaks MSIs on some platforms such as POWER machines.

    We used to have a powerpc specific quirk to address that on a
    single card, but this doesn't scale very well, this is better
    put under control of the drivers who know precisely what a given
    HW revision can do.

    We now have a generic quirk in the PCI code. We should set it
    appropriately for all radeon's from the audio driver.

    Signed-off-by: Benjamin Herrenschmidt
    Reviewed-by: Takashi Iwai
    Reviewed-by: Alex Deucher
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit c6c15e1ed303ffc47e696ea1c9a9df1761c1f603 upstream.

    The currect code for nfsd41_cb_get_slot() and nfsd4_cb_done() has no
    locking in order to guarantee atomicity, and so allows for races of
    the form.

    Task 1 Task 2
    ====== ======
    if (test_and_set_bit(0) != 0) {
    clear_bit(0)
    rpc_wake_up_next(queue)
    rpc_sleep_on(queue)
    return false;
    }

    This patch breaks the race condition by adding a retest of the bit
    after the call to rpc_sleep_on().

    Signed-off-by: Trond Myklebust
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit 6d0ba0432a5e10bc714ba9c5adc460e726e5fbb4 upstream.

    Even when security labels are disabled we support at least the same
    attributes as v4.1.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Greg Kroah-Hartman

    Christoph Hellwig
     
  • commit 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b upstream.

    The length counting previously done had an error in it, causing
    the length down the data dumping function to be shorter than it
    should be, causing the end of the data to get truncated off and
    lost.

    Fixes: 67c65f2cf710 ("iwlwifi: dump periphery registers to fw-error-dump")
    Signed-off-by: Liad Kaufman
    Reviewed-by: Johannes Berg
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Greg Kroah-Hartman

    Liad Kaufman
     
  • commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

    RT2800 and newer hardware require padding between header and payload if
    header length is not multiple of 4.

    For historical reasons we also align payload to to 4 bytes boundary, but
    such alignment is not needed on modern H/W.

    Patch fixes skb_under_panic problems reported from time to time:

    https://bugzilla.kernel.org/show_bug.cgi?id=84911
    https://bugzilla.kernel.org/show_bug.cgi?id=72471
    http://marc.info/?l=linux-wireless&m=139108549530402&w=2
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

    Panic happened because we eat 4 bytes of skb headroom on each
    (re)transmission when sending frame without the payload and the header
    length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
    case because paylad_aling=2 is bigger than header_align=0 we increase
    header_align by 4 bytes. To prevent that we could change the check to:

    if (payload_length && payload_align > header_align)
    header_align += 4;

    but not aligning payload at all is more effective and alignment is not
    really needed by H/W (that has been tested on OpenWrt project for few
    years now).

    Reported-and-tested-by: Antti S. Lankila
    Debugged-by: Antti S. Lankila
    Reported-by: Henrik Asp
    Originally-From: Helmut Schaa
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Stanislaw Gruszka
     
  • commit 1f9cd915b64bb95f7b41667b4bf8b22f0a0a557b upstream.

    The prep_memcpy call was not setting any meaningful burst and width because it
    was relying on the dma_slave_config was not set already.

    Rework the needed conversion functions, and hardcode the width and burst to
    use.

    Signed-off-by: Maxime Ripard
    Signed-off-by: Vinod Koul
    Signed-off-by: Greg Kroah-Hartman

    Maxime Ripard
     
  • commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.

    ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
    Error) interrupt, which triggers the folloing warning:

    [ 1153.360705] ------------[ cut here ]------------
    [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
    [ 1153.360772] Call Trace:
    [ 1153.360778] [] dump_stack+0x41/0x52
    [ 1153.360782] [] warn_slowpath_common+0x7e/0xa0
    [ 1153.360784] [] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360786] [] ? skb_release_head_state+0xb9/0xd0
    [ 1153.360788] [] warn_slowpath_null+0x22/0x30
    [ 1153.360791] [] skb_release_head_state+0xb9/0xd0
    [ 1153.360793] [] skb_release_all+0x10/0x30
    [ 1153.360795] [] kfree_skb+0x36/0x80
    [ 1153.360799] [] ? can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360802] [] can_free_echo_skb+0x28/0x40 [can_dev]
    [ 1153.360805] [] esd_pci402_interrupt+0x34c/0x57a [esd402]
    [ 1153.360809] [] handle_irq_event_percpu+0x35/0x180
    [ 1153.360811] [] ? handle_irq_event_percpu+0xa3/0x180
    [ 1153.360813] [] handle_irq_event+0x31/0x50
    [ 1153.360816] [] handle_fasteoi_irq+0x6f/0x120
    [ 1153.360818] [] ? handle_edge_irq+0x110/0x110
    [ 1153.360822] [] handle_irq+0x71/0x90
    [ 1153.360823] [] do_IRQ+0x3c/0xd0
    [ 1153.360829] [] common_interrupt+0x2c/0x34
    [ 1153.360834] [] ? finish_task_switch+0x47/0xf0
    [ 1153.360836] [] __schedule+0x35b/0x7e0
    [ 1153.360839] [] ? console_unlock+0x2c4/0x4d0
    [ 1153.360842] [] ? n_tty_receive_buf_common+0x890/0x890
    [ 1153.360845] [] ? process_one_work+0x196/0x370
    [ 1153.360847] [] schedule+0x23/0x60
    [ 1153.360849] [] worker_thread+0x161/0x460
    [ 1153.360852] [] ? __wake_up_locked+0x1f/0x30
    [ 1153.360854] [] ? rescuer_thread+0x2f0/0x2f0
    [ 1153.360856] [] kthread+0xa1/0xc0
    [ 1153.360859] [] ret_from_kernel_thread+0x21/0x30
    [ 1153.360861] [] ? kthread_create_on_node+0x110/0x110
    [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---

    This patch replaces the kfree_skb() by dev_kfree_skb_any().

    Signed-off-by: Thomas Körper
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Greg Kroah-Hartman

    Thomas Körper
     
  • commit 1899045510ff109980d9cc34e330fd8ca3631871 upstream.

    Intel Multi-Flex LUNs choke on REPORT SUPPORTED OPERATION CODES
    resulting in sd_mod hanging for several minutes on startup.
    The issue was introduced with WRITE SAME discovery heuristics.

    Fixes: 5db44863b6eb ("[SCSI] sd: Implement support for WRITE SAME")
    Signed-off-by: Christian Sünkenberg
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Greg Kroah-Hartman

    Christian Sünkenberg
     
  • commit ab8edab132829b26dd13db6caca3c242cce35dc1 upstream.

    This patch addresses a bug where individual vhost-scsi configfs endpoint
    groups can be removed from below while active exports to QEMU userspace
    still exist, resulting in an OOPs.

    It adds a configfs_depend_item() in vhost_scsi_set_endpoint() to obtain
    an explicit dependency on se_tpg->tpg_group in order to prevent individual
    vhost-scsi WWPN endpoints from being released via normal configfs methods
    while an QEMU ioctl reference still exists.

    Also, add matching configfs_undepend_item() in vhost_scsi_clear_endpoint()
    to release the dependency, once QEMU's reference to the individual group
    at /sys/kernel/config/target/vhost/$WWPN/$TPGT is released.

    (Fix up vhost_scsi_clear_endpoint() error path - DanC)

    Cc: Michael S. Tsirkin
    Cc: Paolo Bonzini
    Cc: Stefan Hajnoczi
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Nicholas Bellinger
     
  • commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d upstream.

    Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
    cryptoapi's CCM driver) introduced a regression when decrypting empty
    packets (data_len == 0). This will lead to backtraces like:

    (scatterwalk_start) from [] (scatterwalk_map_and_copy+0x2c/0xa8)
    (scatterwalk_map_and_copy) from [] (crypto_ccm_decrypt+0x7c/0x25c)
    (crypto_ccm_decrypt) from [] (ieee80211_aes_ccm_decrypt+0x160/0x170)
    (ieee80211_aes_ccm_decrypt) from [] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
    (ieee80211_crypto_ccmp_decrypt) from [] (ieee80211_rx_handlers+0x870/0x1d24)
    (ieee80211_rx_handlers) from [] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
    (ieee80211_prepare_and_rx_handle) from [] (ieee80211_rx+0x568/0x730)
    (ieee80211_rx) from [] (__carl9170_rx+0x94c/0xa20)
    (__carl9170_rx) from [] (carl9170_rx_stream+0x1fc/0x320)
    (carl9170_rx_stream) from [] (carl9170_usb_tasklet+0x80/0xc8)
    (carl9170_usb_tasklet) from [] (tasklet_hi_action+0x88/0xcc)
    (tasklet_hi_action) from [] (__do_softirq+0xcc/0x200)
    (__do_softirq) from [] (irq_exit+0x80/0xe0)
    (irq_exit) from [] (handle_IRQ+0x64/0x80)
    (handle_IRQ) from [] (__irq_svc+0x40/0x4c)
    (__irq_svc) from [] (arch_cpu_idle+0x2c/0x34)

    Such packets can appear for example when using the carl9170 wireless driver
    because hardware sometimes generates garbage when the internal FIFO overruns.

    This patch adds an additional length check.

    Fixes: 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver")
    Acked-by: Ard Biesheuvel
    Signed-off-by: Ronald Wahl
    Signed-off-by: Johannes Berg
    Signed-off-by: Greg Kroah-Hartman

    Ronald Wahl
     
  • commit 9c4b19a07dddda3ba35a2eb9b4134d485908e2f5 upstream.

    commit 8c328a262f ("spi: sirf: Avoid duplicate code in various
    bits_per_word cases") is wrong in setting data width register of
    fifo is not right, it should use sspi->word_width >> 1 to set
    related bits. According to hardware spec, the mapping between
    register value and data width:
    0 - byte
    1 - WORD
    2 - DWORD

    Fixes: 8c328a262f ("spi: sirf: Avoid duplicate code in various bits_per_word cases") is wrong in setting data width register of
    Signed-off-by: Qipan Li
    Signed-off-by: Barry Song
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Qipan Li
     
  • commit c1aefbdd050e1fb15e92bcaf34d95b17ea952097 upstream.

    We can only use page_address on memory that has been mapped using kmap,
    when the buffer passed to the SPI has been allocated by vmalloc the page
    has not necessarily been mapped through kmap. This means sometimes
    page_address will return NULL causing the pointer we pass to sg_set_buf
    to be invalid.

    As we only call page_address so that we can pass a virtual address to
    sg_set_buf which will then immediately call virt_to_page on it, fix this
    by calling sg_set_page directly rather then relying on the sg_set_buf
    helper.

    Signed-off-by: Charles Keepax
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Charles Keepax
     
  • commit 0a8727e69778683495058852f783eeda141a754e upstream.

    An IOCTL call that calls spi_setup() and then dw_spi_setup() will
    overwrite the persisted last transfer speed. On each transfer, the
    SPI speed is compared to the last transfer speed to determine if the
    clock divider registers need to be updated (did the speed change?).
    This bug was observed with the spidev driver using spi-config to
    update the max transfer speed.

    This fix: Don't overwrite the persisted last transaction clock speed
    when updating the SPI parameters in dw_spi_setup(). On the next
    transaction, the new speed won't match the persisted last speed
    and the hardware registers will be updated.
    On initialization, the persisted last transaction clock
    speed will be 0 but will be updated after the first SPI
    transaction.

    Move zeroed clock divider check into clock change test because
    chip->clk_div is zero on startup and would cause a divide-by-zero
    error. The calculation was wrong as well (can't support odd #).

    Reported-by: Vlastimil Setka
    Signed-off-by: Vlastimil Setka
    Signed-off-by: Thor Thayer
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Thor Thayer
     
  • commit 3b726ae2de02a406cc91903f80132daee37b6f1b upstream.

    In this case the cm_id->context is the isert_np, and the cm_id->qp
    is NULL, so use that to distinct the cases.

    Since we don't expect any other events on this cm_id we can
    just return -1 for explicit termination of the cm_id by the
    cma layer.

    Signed-off-by: Sagi Grimberg
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Sagi Grimberg
     
  • commit 885e7b0e181c14e4d0ddd26c688bad2b84c1ada9 upstream.

    If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
    sets the transfer direction in the transport layer to indicate a
    data-out phase, we still shouldn't try to transfer data. At best it's
    a NOP, and depending on the transport, we might crash on an
    uninitialized sg list.

    Reported-by: Craig Watson
    Signed-off-by: Roland Dreier
    Signed-off-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Roland Dreier