05 Sep, 2018

6 commits

  • [ Upstream commit 19103a4bfb42f320395daa5616ece3e89e759d63 ]

    As part of hw reconfig, only stations linked to AP interfaces are added
    back to the driver ignoring those which are tied to AP_VLAN interfaces.

    It is true that there could be stations tied to the AP_VLAN interface while
    serving 4addr clients or when using AP_VLAN for VLAN operations; we should
    be adding these stations back to the driver as part of hw reconfig, failing
    to do so can cause functional issues.

    In the case of ath10k driver, the following errors were observed.

    ath10k_pci : failed to install key for non-existent peer XX:XX:XX:XX:XX:XX
    Workqueue: events_freezable ieee80211_restart_work [mac80211]
    (unwind_backtrace) from (show_stack+0x10/0x14)
    (show_stack) (dump_stack+0x80/0xa0)
    (dump_stack) (warn_slowpath_common+0x68/0x8c)
    (warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
    (warn_slowpath_null) (ieee80211_enable_keys+0x88/0x154 [mac80211])
    (ieee80211_enable_keys) (ieee80211_reconfig+0xc90/0x19c8 [mac80211])
    (ieee80211_reconfig]) (ieee80211_restart_work+0x8c/0xa0 [mac80211])
    (ieee80211_restart_work) (process_one_work+0x284/0x488)
    (process_one_work) (worker_thread+0x228/0x360)
    (worker_thread) (kthread+0xd8/0xec)
    (kthread) (ret_from_fork+0x14/0x24)

    Also while bringing down the AP VAP, WARN_ONs and errors related to peer
    removal were observed.

    ath10k_pci : failed to clear all peer wep keys for vdev 0: -2
    ath10k_pci : failed to disassociate station: 8c:fd:f0:0a:8c:f5 vdev 0: -2
    (unwind_backtrace) (show_stack+0x10/0x14)
    (show_stack) (dump_stack+0x80/0xa0)
    (dump_stack) (warn_slowpath_common+0x68/0x8c)
    (warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
    (warn_slowpath_null) (sta_set_sinfo+0xb98/0xc9c [mac80211])
    (sta_set_sinfo [mac80211]) (__sta_info_flush+0xf0/0x134 [mac80211])
    (__sta_info_flush [mac80211]) (ieee80211_stop_ap+0xe8/0x390 [mac80211])
    (ieee80211_stop_ap [mac80211]) (__cfg80211_stop_ap+0xe0/0x3dc [cfg80211])
    (__cfg80211_stop_ap [cfg80211]) (cfg80211_stop_ap+0x30/0x44 [cfg80211])
    (cfg80211_stop_ap [cfg80211]) (genl_rcv_msg+0x274/0x30c)
    (genl_rcv_msg) (netlink_rcv_skb+0x58/0xac)
    (netlink_rcv_skb) (genl_rcv+0x20/0x34)
    (genl_rcv) (netlink_unicast+0x11c/0x204)
    (netlink_unicast) (netlink_sendmsg+0x30c/0x370)
    (netlink_sendmsg) (sock_sendmsg+0x70/0x84)
    (sock_sendmsg) (___sys_sendmsg.part.3+0x188/0x228)
    (___sys_sendmsg.part.3) (__sys_sendmsg+0x4c/0x70)
    (__sys_sendmsg) (ret_fast_syscall+0x0/0x44)

    These issues got fixed by adding the stations which are
    tied to AP_VLANs back to the driver.

    Signed-off-by: Manikanta Pubbisetty
    Signed-off-by: Johannes Berg
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    mpubbise@codeaurora.org
     
  • [ Upstream commit 7284fdf39a912322ce97de2d30def3c6068a418c ]

    This ought to be an omission in e6194923237 ("esp: Fix memleaks on error
    paths."). The memleak on error path in esp6_input is similar to esp_input
    of esp4.

    Fixes: e6194923237 ("esp: Fix memleaks on error paths.")
    Fixes: 3f29770723f ("ipsec: check return value of skb_to_sgvec always")
    Signed-off-by: Zhen Lei
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Zhen Lei
     
  • [ Upstream commit 86126b77dcd551ce223e7293bb55854e3df05646 ]

    nlmsg_multicast() always frees the skb, so in case we cannot call
    it we must do that ourselves.

    Fixes: 21ee543edc0dea ("xfrm: fix race between netns cleanup and state expire notification")
    Signed-off-by: Florian Westphal
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Florian Westphal
     
  • [ Upstream commit 8cc88773855f988d6a3bbf102bbd9dd9c828eb81 ]

    Fix missing dst_release() when local broadcast or multicast traffic is
    xfrm policy blocked.

    For IPv4 this results to dst leak: ip_route_output_flow() allocates
    dst_entry via __ip_route_output_key() and passes it to
    xfrm_lookup_route(). xfrm_lookup returns ERR_PTR(-EPERM) that is
    propagated. The dst that was allocated is never released.

    IPv4 local broadcast testcase:
    ping -b 192.168.1.255 &
    sleep 1
    ip xfrm policy add src 0.0.0.0/0 dst 192.168.1.255/32 dir out action block

    IPv4 multicast testcase:
    ping 224.0.0.1 &
    sleep 1
    ip xfrm policy add src 0.0.0.0/0 dst 224.0.0.1/32 dir out action block

    For IPv6 the missing dst_release() causes trouble e.g. when used in netns:
    ip netns add TEST
    ip netns exec TEST ip link set lo up
    ip link add dummy0 type dummy
    ip link set dev dummy0 netns TEST
    ip netns exec TEST ip addr add fd00::1111 dev dummy0
    ip netns exec TEST ip link set dummy0 up
    ip netns exec TEST ping -6 -c 5 ff02::1%dummy0 &
    sleep 1
    ip netns exec TEST ip xfrm policy add src ::/0 dst ff02::1 dir out action block
    wait
    ip netns del TEST

    After netns deletion we see:
    [ 258.239097] unregister_netdevice: waiting for lo to become free. Usage count = 2
    [ 268.279061] unregister_netdevice: waiting for lo to become free. Usage count = 2
    [ 278.367018] unregister_netdevice: waiting for lo to become free. Usage count = 2
    [ 288.375259] unregister_netdevice: waiting for lo to become free. Usage count = 2

    Fixes: ac37e2515c1a ("xfrm: release dst_orig in case of error in xfrm_lookup()")
    Signed-off-by: Tommi Rantala
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Tommi Rantala
     
  • [ Upstream commit d6990976af7c5d8f55903bfb4289b6fb030bf754 ]

    When setting the skb->dst before doing the MTU check, the route PMTU
    caching and reporting is done on the new dst which is about to be
    released.

    Instead, PMTU handling should be done using the original dst.

    This is aligned with IPv4 VTI.

    Fixes: ccd740cbc6 ("vti6: Add pmtu handling to vti6_xmit.")
    Signed-off-by: Eyal Birger
    Signed-off-by: Steffen Klassert
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Eyal Birger
     
  • commit e666d4e9ceec94c0a88c94b7db31d56474da43b3 upstream.

    Signed-off-by: Paulo Flabiano Smorigo
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Paulo Flabiano Smorigo
     

24 Aug, 2018

34 commits

  • Greg Kroah-Hartman
     
  • commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream.

    This fixes the following issues:

    - When a buffer size is supplied to reiserfs_listxattr() such that each
    individual name fits, but the concatenation of all names doesn't fit,
    reiserfs_listxattr() overflows the supplied buffer. This leads to a
    kernel heap overflow (verified using KASAN) followed by an out-of-bounds
    usercopy and is therefore a security bug.

    - When a buffer size is supplied to reiserfs_listxattr() such that a
    name doesn't fit, -ERANGE should be returned. But reiserfs instead just
    truncates the list of names; I have verified that if the only xattr on a
    file has a longer name than the supplied buffer length, listxattr()
    incorrectly returns zero.

    With my patch applied, -ERANGE is returned in both cases and the memory
    corruption doesn't happen anymore.

    Credit for making me clean this code up a bit goes to Al Viro, who pointed
    out that the ->actor calling convention is suboptimal and should be
    changed.

    Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
    Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
    Signed-off-by: Jann Horn
    Acked-by: Jeff Mahoney
    Cc: Eric Biggers
    Cc: Al Viro
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Jann Horn
     
  • commit bed4ff1ed4d8f2ef5007c5c6ae1b29c5677a3632 upstream.

    This fixes a race condition, where the DMAEN bit ends up being set after
    I2C slave has transmitted a byte following the dummy read. When that
    happens, an interrupt is generated instead, and no DMA request is generated
    to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).

    Fixed by setting the DMAEN bit before the dummy read.

    Signed-off-by: Esben Haabendal
    Acked-by: Uwe Kleine-König
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Esben Haabendal
     
  • commit c463a158cb6c5d9a85b7d894cd4f8116e8bd6be0 upstream.

    acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
    is the number of transfers executed on success, so 1.

    The ACPI code expects us to store 0 in gsb->status for success, not 1.

    Specifically this breaks the following code in the Thinkpad 8 DSDT:

    ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
    If ((ECST == Zero))
    {
    ECRD = I2CR /* \_SB_.I2C1.I2CR */
    }

    Before this commit we set ECST to 1, causing the read to never happen
    breaking battery monitoring on the Thinkpad 8.

    This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
    returns 1, so the single write transfer completed successfully, and
    makes it return -EIO on for other (unexpected) return values >= 0.

    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede
    Acked-by: Mika Westerberg
    Signed-off-by: Wolfram Sang
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit 1204e35bedf4e5015cda559ed8c84789a6dae24e upstream.

    Commit b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
    events for a device") iterates over the devices on a hotplug port's
    subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
    It is thus possible for a user to cause a crash by concurrently
    manipulating the device list, e.g. by disabling slot power via sysfs
    on a different CPU or by initiating a remove/rescan via sysfs.

    This can't be fixed by acquiring pci_bus_sem because it may sleep.
    The simplest fix is to avoid the list iteration altogether and just
    check the ignore_hotplug flag on the port itself. This works because
    pci_ignore_hotplug() sets the flag both on the device as well as on its
    parent bridge.

    We do lose the ability to print the name of the device blocking hotplug
    in the debug message, but that's probably bearable.

    Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Lukas Wunner
     
  • commit 281e878eab191cce4259abbbf1a0322e3adae02c upstream.

    When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
    hotplug_slot struct is deregistered and thus freed before freeing the
    IRQ. The IRQ handler and the work items it schedules print the slot
    name referenced from the freed structure in various informational and
    debug log messages, each time resulting in a quadruple dereference of
    freed pointers (hotplug_slot -> pci_slot -> kobject -> name).

    At best the slot name is logged as "(null)", at worst kernel memory is
    exposed in logs or the driver crashes:

    pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present

    An attacker may provoke the bug by unplugging multiple devices on a
    Thunderbolt daisy chain at once. Unplugging can also be simulated by
    powering down slots via sysfs. The bug is particularly easy to trigger
    in poll mode.

    It has been present since the driver's introduction in 2004:
    https://git.kernel.org/tglx/history/c/c16b4b14d980

    Fix by rearranging teardown such that the IRQ is freed first. Run the
    work items queued by the IRQ handler to completion before freeing the
    hotplug_slot struct by draining the work queue from the ->release_slot
    callback which is invoked by pci_hp_deregister().

    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Cc: stable@vger.kernel.org # v2.6.4
    Signed-off-by: Greg Kroah-Hartman

    Lukas Wunner
     
  • commit 3dbe97efe8bf450b183d6dee2305cbc032e6b8a4 upstream.

    PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
    Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
    VFs. Just prior to the table it states:

    "PF and VF functionality is defined in Section 7.5.3.4 except where
    noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting
    applies to the VF."

    All of which implies that with respect to Max_Payload_Size Supported
    (MPSS), MPS, and MRRS values, we should not be paying any attention to the
    VF's fields, but rather only to the PF's. Only looking at the PF's fields
    also logically makes sense as it's the sole physical interface to the PCIe
    bus.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
    Fixes: 27d868b5e6cf ("PCI: Set MPS to match upstream bridge")
    Signed-off-by: Myron Stowe
    Signed-off-by: Bjorn Helgaas
    Cc: stable@vger.kernel.org # 4.3+
    Cc: Keith Busch
    Cc: Sinan Kaya
    Cc: Dongdong Liu
    Cc: Jon Mason
    Signed-off-by: Greg Kroah-Hartman

    Myron Stowe
     
  • commit 4ce6435820d1f1cc2c2788e232735eb244bcc8a3 upstream.

    If addition of sysfs files fails on registration of a hotplug slot, the
    struct pci_slot as well as the entry in the slot_list is leaked. The
    issue has been present since the hotplug core was introduced in 2002:
    https://git.kernel.org/tglx/history/c/a8a2069f432c

    Perhaps the idea was that even though sysfs addition fails, the slot
    should still be usable. But that's not how drivers use the interface,
    they abort probe if a non-zero value is returned.

    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Cc: stable@vger.kernel.org # v2.4.15+
    Cc: Greg Kroah-Hartman
    Signed-off-by: Greg Kroah-Hartman

    Lukas Wunner
     
  • commit 3b885ac1dc35b87a39ee176a6c7e2af9c789d8b8 upstream.

    Now that mb() is an instruction barrier, it will slow performance if we issue
    unnecessary barriers.

    The spinlock defines have a number of unnecessary barriers.  The __ldcw()
    define is both a hardware and compiler barrier.  The mb() barriers in the
    routines using __ldcw() serve no purpose.

    The only barrier needed is the one in arch_spin_unlock().  We need to ensure
    all accesses are complete prior to releasing the lock.

    Signed-off-by: John David Anglin
    Cc: stable@vger.kernel.org # 4.0+
    Signed-off-by: Helge Deller
    Signed-off-by: Greg Kroah-Hartman

    John David Anglin
     
  • commit caa21e19e08d7a1445116a93f7ab4e187ebbbadb upstream.

    Invoking shutdown for a socket in state SMC_LISTEN does not make
    sense. Nevertheless programs like syzbot fuzzing the kernel may
    try to do this. For SMC this means a socket refcounting problem.
    This patch makes sure a shutdown call for an SMC socket in state
    SMC_LISTEN simply returns with -ENOTCONN.

    Signed-off-by: Ursula Braun
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Ursula Braun
     
  • commit 4576cd469d980317c4edd9173f8b694aa71ea3a3 upstream.

    TPACKET_V3 stores variable length frames in fixed length blocks.
    Blocks must be able to store a block header, optional private space
    and at least one minimum sized frame.

    Frames, even for a zero snaplen packet, store metadata headers and
    optional reserved space.

    In the block size bounds check, ensure that the frame of the
    chosen configuration fits. This includes sockaddr_ll and optional
    tp_reserve.

    Syzbot was able to construct a ring with insuffient room for the
    sockaddr_ll in the header of a zero-length frame, triggering an
    out-of-bounds write in dev_parse_header.

    Convert the comparison to less than, as zero is a valid snap len.
    This matches the test for minimum tp_frame_size immediately below.

    Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
    Fixes: eb73190f4fbe ("net/packet: refine check for priv area size")
    Reported-by: syzbot
    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Willem de Bruijn
     
  • commit 6613b6173dee098997229caf1f3b961c49da75e6 upstream.

    When first DCCP packet is SYNC or SYNCACK, we insert a new conntrack
    that has an un-initialized timeout value, i.e. such entry could be
    reaped at any time.

    Mark them as INVALID and only ignore SYNC/SYNCACK when connection had
    an old state.

    Reported-by: syzbot+6f18401420df260e37ed@syzkaller.appspotmail.com
    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Greg Kroah-Hartman

    Florian Westphal
     
  • commit 45c180bc29babbedd6b8c01b975780ef44d9d09c upstream.

    struct xfrm_userpolicy_type has two holes, so we should not
    use C99 style initializer.

    KMSAN report:

    BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:140 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
    CPU: 1 PID: 4520 Comm: syz-executor841 Not tainted 4.17.0+ #5
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
    __dump_stack lib/dump_stack.c:77 [inline]
    dump_stack+0x185/0x1d0 lib/dump_stack.c:113
    kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1117
    kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1211
    kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
    copyout lib/iov_iter.c:140 [inline]
    _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
    copy_to_iter include/linux/uio.h:106 [inline]
    skb_copy_datagram_iter+0x422/0xfa0 net/core/datagram.c:431
    skb_copy_datagram_msg include/linux/skbuff.h:3268 [inline]
    netlink_recvmsg+0x6f1/0x1900 net/netlink/af_netlink.c:1959
    sock_recvmsg_nosec net/socket.c:802 [inline]
    sock_recvmsg+0x1d6/0x230 net/socket.c:809
    ___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
    __sys_recvmmsg+0x58e/0xe30 net/socket.c:2391
    do_sys_recvmmsg+0x2a6/0x3e0 net/socket.c:2472
    __do_sys_recvmmsg net/socket.c:2485 [inline]
    __se_sys_recvmmsg net/socket.c:2481 [inline]
    __x64_sys_recvmmsg+0x15d/0x1c0 net/socket.c:2481
    do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x446ce9
    RSP: 002b:00007fc307918db8 EFLAGS: 00000293 ORIG_RAX: 000000000000012b
    RAX: ffffffffffffffda RBX: 00000000006dbc24 RCX: 0000000000446ce9
    RDX: 000000000000000a RSI: 0000000020005040 RDI: 0000000000000003
    RBP: 00000000006dbc20 R08: 0000000020004e40 R09: 0000000000000000
    R10: 0000000040000000 R11: 0000000000000293 R12: 0000000000000000
    R13: 00007ffc8d2df32f R14: 00007fc3079199c0 R15: 0000000000000001

    Uninit was stored to memory at:
    kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
    kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
    kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
    kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
    __msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:413
    __nla_put lib/nlattr.c:569 [inline]
    nla_put+0x276/0x340 lib/nlattr.c:627
    copy_to_user_policy_type net/xfrm/xfrm_user.c:1678 [inline]
    dump_one_policy+0xbe1/0x1090 net/xfrm/xfrm_user.c:1708
    xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
    xfrm_dump_policy+0x1c0/0x2a0 net/xfrm/xfrm_user.c:1749
    netlink_dump+0x9b5/0x1550 net/netlink/af_netlink.c:2226
    __netlink_dump_start+0x1131/0x1270 net/netlink/af_netlink.c:2323
    netlink_dump_start include/linux/netlink.h:214 [inline]
    xfrm_user_rcv_msg+0x8a3/0x9b0 net/xfrm/xfrm_user.c:2577
    netlink_rcv_skb+0x37e/0x600 net/netlink/af_netlink.c:2448
    xfrm_netlink_rcv+0xb2/0xf0 net/xfrm/xfrm_user.c:2598
    netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
    netlink_unicast+0x1680/0x1750 net/netlink/af_netlink.c:1336
    netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
    sock_sendmsg_nosec net/socket.c:629 [inline]
    sock_sendmsg net/socket.c:639 [inline]
    ___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
    __sys_sendmsg net/socket.c:2155 [inline]
    __do_sys_sendmsg net/socket.c:2164 [inline]
    __se_sys_sendmsg net/socket.c:2162 [inline]
    __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
    do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    Local variable description: ----upt.i@dump_one_policy
    Variable was created at:
    dump_one_policy+0x78/0x1090 net/xfrm/xfrm_user.c:1689
    xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013

    Byte 130 of 137 is uninitialized
    Memory access starts at ffff88019550407f

    Fixes: c0144beaeca42 ("[XFRM] netlink: Use nla_put()/NLA_PUT() variantes")
    Signed-off-by: Eric Dumazet
    Reported-by: syzbot
    Cc: Steffen Klassert
    Cc: Herbert Xu
    Signed-off-by: Steffen Klassert
    Signed-off-by: Greg Kroah-Hartman

    Eric Dumazet
     
  • commit 7797167ffde1f00446301cb22b37b7c03194cfaf upstream.

    Now that we use a sync prior to releasing the locks in syscall.S, we don't need
    the PA 2.0 ordered stores used to release some locks.  Using an ordered store,
    potentially slows the release and subsequent code.

    There are a number of other ordered stores and loads that serve no purpose.  I
    have converted these to normal stores.

    Signed-off-by: John David Anglin
    Cc: stable@vger.kernel.org # 4.0+
    Signed-off-by: Helge Deller
    Signed-off-by: Greg Kroah-Hartman

    John David Anglin
     
  • commit 8a29c1260e24e7c9c6ab138aa0017558d8b28208 upstream.

    This patch enhances sanity check for SIT entries.

    syzbot hit the following crash on upstream commit
    83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +0000)
    Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
    syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=bf9253040425feb155ad

    syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=5692130282438656
    Raw console output: https://syzkaller.appspot.com/x/log.txt?id=5095924598571008
    Kernel config: https://syzkaller.appspot.com/x/.config?id=1808800213120130118
    compiler: gcc (GCC) 8.0.1 20180413 (experimental)

    IMPORTANT: if you fix the bug, please add the following tag to the commit:
    Reported-by: syzbot+bf9253040425feb155ad@syzkaller.appspotmail.com
    It will help syzbot understand when the bug is fixed. See footer for details.
    If you forward the report, please keep this part and the footer.

    F2FS-fs (loop0): invalid crc value
    F2FS-fs (loop0): Try to recover 1th superblock, ret: 0
    F2FS-fs (loop0): Mounted with checkpoint version = d
    F2FS-fs (loop0): Bitmap was wrongly cleared, blk:9740
    ------------[ cut here ]------------
    kernel BUG at fs/f2fs/segment.c:1884!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
    (ftrace buffer empty)
    Modules linked in:
    CPU: 1 PID: 4508 Comm: syz-executor0 Not tainted 4.17.0-rc1+ #10
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:update_sit_entry+0x1215/0x1590 fs/f2fs/segment.c:1882
    RSP: 0018:ffff8801af526708 EFLAGS: 00010282
    RAX: ffffed0035ea4cc0 RBX: ffff8801ad454f90 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff82eeb87e RDI: ffffed0035ea4cb6
    RBP: ffff8801af526760 R08: ffff8801ad4a2480 R09: ffffed003b5e4f90
    R10: ffffed003b5e4f90 R11: ffff8801daf27c87 R12: ffff8801adb8d380
    R13: 0000000000000001 R14: 0000000000000008 R15: 00000000ffffffff
    FS: 00000000014af940(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f06bc223000 CR3: 00000001adb02000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    allocate_data_block+0x66f/0x2050 fs/f2fs/segment.c:2663
    do_write_page+0x105/0x1b0 fs/f2fs/segment.c:2727
    write_node_page+0x129/0x350 fs/f2fs/segment.c:2770
    __write_node_page+0x7da/0x1370 fs/f2fs/node.c:1398
    sync_node_pages+0x18cf/0x1eb0 fs/f2fs/node.c:1652
    block_operations+0x429/0xa60 fs/f2fs/checkpoint.c:1088
    write_checkpoint+0x3ba/0x5380 fs/f2fs/checkpoint.c:1405
    f2fs_sync_fs+0x2fb/0x6a0 fs/f2fs/super.c:1077
    __sync_filesystem fs/sync.c:39 [inline]
    sync_filesystem+0x265/0x310 fs/sync.c:67
    generic_shutdown_super+0xd7/0x520 fs/super.c:429
    kill_block_super+0xa4/0x100 fs/super.c:1191
    kill_f2fs_super+0x9f/0xd0 fs/f2fs/super.c:3030
    deactivate_locked_super+0x97/0x100 fs/super.c:316
    deactivate_super+0x188/0x1b0 fs/super.c:347
    cleanup_mnt+0xbf/0x160 fs/namespace.c:1174
    __cleanup_mnt+0x16/0x20 fs/namespace.c:1181
    task_work_run+0x1e4/0x290 kernel/task_work.c:113
    tracehook_notify_resume include/linux/tracehook.h:191 [inline]
    exit_to_usermode_loop+0x2bd/0x310 arch/x86/entry/common.c:166
    prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
    syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
    do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
    entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x457d97
    RSP: 002b:00007ffd46f9c8e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000457d97
    RDX: 00000000014b09a3 RSI: 0000000000000002 RDI: 00007ffd46f9da50
    RBP: 00007ffd46f9da50 R08: 0000000000000000 R09: 0000000000000009
    R10: 0000000000000005 R11: 0000000000000246 R12: 00000000014b0940
    R13: 0000000000000000 R14: 0000000000000002 R15: 000000000000658e
    RIP: update_sit_entry+0x1215/0x1590 fs/f2fs/segment.c:1882 RSP: ffff8801af526708
    ---[ end trace f498328bb02610a2 ]---

    Reported-and-tested-by: syzbot+bf9253040425feb155ad@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+7d6d31d3bc702f566ce3@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+0a725420475916460f12@syzkaller.appspotmail.com
    Reviewed-by: Chao Yu
    Signed-off-by: Jaegeuk Kim
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Jaegeuk Kim
     
  • commit c39a1b348c4fe172729eff77c533dabc3c7cdaa7 upstream.

    Let's avoid BUG_ON during fill_super, when on-disk was totall corrupted.

    Reviewed-by: Chao Yu
    Signed-off-by: Jaegeuk Kim
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Jaegeuk Kim
     
  • commit 9432a3175770e06cb83eada2d91fac90c977cb99 upstream.

    A comment warning against this bug is there, but the code is not doing what
    the comment says. Therefore it is possible that an EPOLLHUP races against
    irq_bypass_register_consumer. The EPOLLHUP handler schedules irqfd_shutdown,
    and if that runs soon enough, you get a use-after-free.

    Reported-by: syzbot
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Bonzini
    Reviewed-by: David Hildenbrand
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Paolo Bonzini
     
  • [ Upstream commit 9b382768135ee3ff282f828c906574a8478e036b ]

    The old code in nvme_user_cmd() passed the userspace virtual address
    from nvme_passthru_cmd.metadata as the length of the metadata buffer
    as well as the address to nvme_submit_user_cmd().

    Fixes: 63263d60 ("nvme: Use metadata for passthrough commands")
    Signed-off-by: Roland Dreier
    Reviewed-by: Keith Busch
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Roland Dreier
     
  • [ Upstream commit e01a06c8089132bb4da035c6a83df23916ca3ebf ]

    The Marvell switches report their interrupts in a level sensitive way.
    When using edge sensitive detection a race condition in the interrupt
    handler of the swich might result in the OS to miss all future events
    which might make the switch non-functional.

    The problem is that both mv88e6xxx_g2_irq_thread_fn() and
    mv88e6xxx_g1_irq_thread_work() sample the irq cause register
    (MV88E6XXX_G2_INT_SRC and MV88E6XXX_G1_STS respectively) once and then
    handle the observed sources. If after sampling but before all observed
    irq sources are handled a new irq source gets active this is not noticed
    by the handler which returns unsuspecting, but the interrupt line stays
    active which prevents the edge detector to kick in.

    All device trees but imx6qdl-zii-rdu2 get this right (most of them by
    not specifying an interrupt parent). So fix imx6qdl-zii-rdu2
    accordingly.

    Signed-off-by: Uwe Kleine-König
    Fixes: f64992d1a916 ("ARM: dts: imx6: RDU2: Add Switch interrupts")
    Reviewed-by: Andrew Lunn
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Uwe Kleine-König
     
  • [ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]

    The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
    beyond matched only a single DMI model (20KGS3JF01), that didn't cover
    my laptop (20KH002JUS). Change to match based on DMI product family to
    cover all X1 6th gen systems.

    Signed-off-by: Robin H. Johnson
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Robin H. Johnson
     
  • [ Upstream commit de2d9b5284bcb5c159c5882ac69f6bfd4dec7c67 ]

    GPC registers are NOT continuous, some registers are
    reserved and accessing them from userspace will trigger
    external abort, add regmap register access table to
    avoid below abort:

    root@imx6slevk:~# cat /sys/kernel/debug/regmap/20dc000.gpc/registers
    [ 108.480477] Unhandled fault: imprecise external abort (0x1406) at 0xb6db5004
    [ 108.487985] pgd = 42b54bfd
    [ 108.490741] [b6db5004] *pgd=ba1b7831
    [ 108.494386] Internal error: : 1406 [#1] SMP ARM
    [ 108.498943] Modules linked in:
    [ 108.502043] CPU: 0 PID: 389 Comm: cat Not tainted 4.18.0-rc1-00074-gc9f1f60-dirty #482
    [ 108.509982] Hardware name: Freescale i.MX6 SoloLite (Device Tree)
    [ 108.516123] PC is at regmap_mmio_read32le+0x20/0x24
    [ 108.521031] LR is at regmap_mmio_read+0x40/0x60
    [ 108.525586] pc : [] lr : [] psr: 20060093
    [ 108.531875] sp : eccf1d98 ip : eccf1da8 fp : eccf1da4
    [ 108.537122] r10: ec2d3800 r9 : eccf1f60 r8 : ecfc0000
    [ 108.542370] r7 : eccf1e2c r6 : eccf1e2c r5 : 00000028 r4 : ec338e00
    [ 108.548920] r3 : 00000000 r2 : eccf1e2c r1 : f0980028 r0 : 00000000
    [ 108.555474] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
    [ 108.562720] Control: 10c5387d Table: acf4004a DAC: 00000051
    [ 108.568491] Process cat (pid: 389, stack limit = 0xd4318a65)
    [ 108.574174] Stack: (0xeccf1d98 to 0xeccf2000)

    Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
    Signed-off-by: Anson Huang
    Reviewed-by: Fabio Estevam
    Signed-off-by: Shawn Guo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Anson Huang
     
  • [ Upstream commit e56b8ce363a36fb7b74b80aaa5cc9084f2c908b4 ]

    Attempt to make cryptic TCP seq number error messages clearer by
    (1) identifying the source of the message as "TCP", (2) identifying the
    errors as "seq # bug", and (3) grouping the field identifiers and values
    by separating them with commas.

    E.g., the following message is changed from:

    recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
    WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90

    to:

    TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 73BCB9AA, fl 0
    WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 tcp_recvmsg+0x694/0xba0

    Suggested-by: 積丹尼 Dan Jacobson
    Signed-off-by: Randy Dunlap
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     
  • [ Upstream commit 50973993260a6934f0a00da53d9b746cfbea89ab ]

    In cases the probing fails the log level of the messages should
    be an error.

    Signed-off-by: Stefan Wahren
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefan Wahren
     
  • [ Upstream commit 711c62dfa6bdb4326ca6c587f295ea5c4f7269de ]

    In case the SPI thread is not running, a simple reset of sync
    state won't fix the transmit timeout. We also need to wake up the kernel
    thread.

    Signed-off-by: Stefan Wahren
    Fixes: ed7d42e24eff ("net: qca_spi: fix transmit queue timeout handling")
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefan Wahren
     
  • [ Upstream commit b2bab426dc715de147f8039a3fccff27d795f4eb ]

    As long as the synchronization with the QCA7000 isn't finished, we
    cannot accept packets from the upper layers. So let the SPI thread
    enable the TX queue after sync and avoid unwanted packet drop.

    Signed-off-by: Stefan Wahren
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stefan Wahren
     
  • [ Upstream commit 0018b265adf7e251f90d3ca1c7c0e32e2a0ad262 ]

    When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY
    driver was left disabled, the kernel crashed with this BUG:

    kernel BUG at lib/ioremap.c:72!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
    Hardware name: Renesas Condor board based on r8a77980 (DT)
    Workqueue: events deferred_probe_work_func
    pstate: 80000005 (Nzcv daif -PAN -UAO)
    pc : ioremap_page_range+0x370/0x3c8
    lr : ioremap_page_range+0x40/0x3c8
    sp : ffff000008da39e0
    x29: ffff000008da39e0 x28: 00e8000000000f07
    x27: ffff7dfffee00000 x26: 0140000000000000
    x25: ffff7dfffef00000 x24: 00000000000fe100
    x23: ffff80007b906000 x22: ffff000008ab8000
    x21: ffff000008bb1d58 x20: ffff7dfffef00000
    x19: ffff800009c30fb8 x18: 0000000000000001
    x17: 00000000000152d0 x16: 00000000014012d0
    x15: 0000000000000000 x14: 0720072007200720
    x13: 0720072007200720 x12: 0720072007200720
    x11: 0720072007300730 x10: 00000000000000ae
    x9 : 0000000000000000 x8 : ffff7dffff000000
    x7 : 0000000000000000 x6 : 0000000000000100
    x5 : 0000000000000000 x4 : 000000007b906000
    x3 : ffff80007c61a880 x2 : ffff7dfffeefffff
    x1 : 0000000040000000 x0 : 00e80000fe100f07
    Process kworker/0:1 (pid: 39, stack limit = 0x (ptrval))
    Call trace:
    ioremap_page_range+0x370/0x3c8
    pci_remap_iospace+0x7c/0xac
    pci_parse_request_of_pci_ranges+0x13c/0x190
    rcar_pcie_probe+0x4c/0xb04
    platform_drv_probe+0x50/0xbc
    driver_probe_device+0x21c/0x308
    __device_attach_driver+0x98/0xc8
    bus_for_each_drv+0x54/0x94
    __device_attach+0xc4/0x12c
    device_initial_probe+0x10/0x18
    bus_probe_device+0x90/0x98
    deferred_probe_work_func+0xb0/0x150
    process_one_work+0x12c/0x29c
    worker_thread+0x200/0x3fc
    kthread+0x108/0x134
    ret_from_fork+0x10/0x18
    Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000)

    It turned out that pci_remap_iospace() wasn't undone when the driver's
    probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
    the probe was retried, finally causing the BUG due to trying to remap
    already remapped pages.

    The Versatile PCI controller driver has the same issue.
    Replace pci_remap_iospace() with the devm_ managed version to fix the bug.

    Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
    Signed-off-by: Sergei Shtylyov
    [lorenzo.pieralisi@arm.com: updated the commit log]
    Signed-off-by: Lorenzo Pieralisi
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sergei Shtylyov
     
  • commit a5fb9fb023a1435f2b42bccd7f547560f3a21dc3 upstream.

    When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY
    driver was left disabled, the kernel crashed with this BUG:

    kernel BUG at lib/ioremap.c:72!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
    Hardware name: Renesas Condor board based on r8a77980 (DT)
    Workqueue: events deferred_probe_work_func
    pstate: 80000005 (Nzcv daif -PAN -UAO)
    pc : ioremap_page_range+0x370/0x3c8
    lr : ioremap_page_range+0x40/0x3c8
    sp : ffff000008da39e0
    x29: ffff000008da39e0 x28: 00e8000000000f07
    x27: ffff7dfffee00000 x26: 0140000000000000
    x25: ffff7dfffef00000 x24: 00000000000fe100
    x23: ffff80007b906000 x22: ffff000008ab8000
    x21: ffff000008bb1d58 x20: ffff7dfffef00000
    x19: ffff800009c30fb8 x18: 0000000000000001
    x17: 00000000000152d0 x16: 00000000014012d0
    x15: 0000000000000000 x14: 0720072007200720
    x13: 0720072007200720 x12: 0720072007200720
    x11: 0720072007300730 x10: 00000000000000ae
    x9 : 0000000000000000 x8 : ffff7dffff000000
    x7 : 0000000000000000 x6 : 0000000000000100
    x5 : 0000000000000000 x4 : 000000007b906000
    x3 : ffff80007c61a880 x2 : ffff7dfffeefffff
    x1 : 0000000040000000 x0 : 00e80000fe100f07
    Process kworker/0:1 (pid: 39, stack limit = 0x (ptrval))
    Call trace:
    ioremap_page_range+0x370/0x3c8
    pci_remap_iospace+0x7c/0xac
    pci_parse_request_of_pci_ranges+0x13c/0x190
    rcar_pcie_probe+0x4c/0xb04
    platform_drv_probe+0x50/0xbc
    driver_probe_device+0x21c/0x308
    __device_attach_driver+0x98/0xc8
    bus_for_each_drv+0x54/0x94
    __device_attach+0xc4/0x12c
    device_initial_probe+0x10/0x18
    bus_probe_device+0x90/0x98
    deferred_probe_work_func+0xb0/0x150
    process_one_work+0x12c/0x29c
    worker_thread+0x200/0x3fc
    kthread+0x108/0x134
    ret_from_fork+0x10/0x18
    Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000)

    It turned out that pci_remap_iospace() wasn't undone when the driver's
    probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
    the probe was retried, finally causing the BUG due to trying to remap
    already remapped pages.

    Introduce the devm_pci_remap_iospace() managed API and replace the
    pci_remap_iospace() call with it to fix the bug.

    Fixes: dbf9826d5797 ("PCI: generic: Convert to DT resource parsing API")
    Signed-off-by: Sergei Shtylyov
    [lorenzo.pieralisi@arm.com: split commit/updated the commit log]
    Signed-off-by: Lorenzo Pieralisi
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Sergei Shtylyov
     
  • [ Upstream commit e10f7805032365cc11c739a97f226ebb48aee042 ]

    Inside a nested guest, access to hardware can be slow enough that
    tsc_read_refs always return ULLONG_MAX, causing tsc_refine_calibration_work
    to be called periodically and the nested guest to spend a lot of time
    reading the ACPI timer.

    However, if the TSC frequency is available from the pvclock page,
    we can just set X86_FEATURE_TSC_KNOWN_FREQ and avoid the recalibration.
    'refine' operation.

    Suggested-by: Peter Zijlstra
    Signed-off-by: Peng Hao
    [Commit message rewritten. - Paolo]
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Peng Hao
     
  • [ Upstream commit 3a9b0455062ffb9d2f6cd4473a76e3456f318c9f ]

    This driver can spam the kernel log with multiple messages of:

    net eth0: eth0: allmulti set

    Usually 4 or 8 at a time (probably because of using ConnMan).

    This message doesn't seem useful, so let's demote it from dev_info()
    to dev_dbg().

    Signed-off-by: David Lechner
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    David Lechner
     
  • [ Upstream commit 4aac0b43474d18f6160302a3caa147d77fa3baa1 ]

    octeon_mgmt driver doesn't drop RX frames that are 1-4 bytes bigger than
    MTU set for the corresponding interface. The problem is in the
    AGL_GMX_RX0/1_FRM_MAX register setting, which should not account for VLAN
    tagging.

    According to Octeon HW manual:
    "For tagged frames, MAX increases by four bytes for each VLAN found up to a
    maximum of two VLANs, or MAX + 8 bytes."

    OCTEON_FRAME_HEADER_LEN "define" is fine for ring buffer management, but
    should not be used for AGL_GMX_RX0/1_FRM_MAX.

    The problem could be easily reproduced using "ping" command. If affected
    system has default MTU 1500, other host (having MTU >= 1504) can
    successfully "ping" the affected system with payload size 1473-1476,
    resulting in IP packets of size 1501-1504 accepted by the mgmt driver.
    Fixed system still accepts IP packets of 1500 bytes even with VLAN tagging,
    because the limits are lifted in HW as expected, for every VLAN tag.

    Signed-off-by: Alexander Sverdlin
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Alexander Sverdlin
     
  • [ Upstream commit 665d4953cde6d9e75c62a07ec8f4f8fd7d396ade ]

    In commit ac0b4145d662 ("btrfs: scrub: Don't use inode pages for device
    replace") we removed the branch of copy_nocow_pages() to avoid
    corruption for compressed nodatasum extents.

    However above commit only solves the problem in scrub_extent(), if
    during scrub_pages() we failed to read some pages,
    sctx->no_io_error_seen will be non-zero and we go to fixup function
    scrub_handle_errored_block().

    In scrub_handle_errored_block(), for sctx without csum (no matter if
    we're doing replace or scrub) we go to scrub_fixup_nodatasum() routine,
    which does the similar thing with copy_nocow_pages(), but does it
    without the extra check in copy_nocow_pages() routine.

    So for test cases like btrfs/100, where we emulate read errors during
    replace/scrub, we could corrupt compressed extent data again.

    This patch will fix it just by avoiding any "optimization" for
    nodatasum, just falls back to the normal fixup routine by try read from
    any good copy.

    This also solves WARN_ON() or dead lock caused by lame backref iteration
    in scrub_fixup_nodatasum() routine.

    The deadlock or WARN_ON() won't be triggered before commit ac0b4145d662
    ("btrfs: scrub: Don't use inode pages for device replace") since
    copy_nocow_pages() have better locking and extra check for data extent,
    and it's already doing the fixup work by try to read data from any good
    copy, so it won't go scrub_fixup_nodatasum() anyway.

    This patch disables the faulty code and will be removed completely in a
    followup patch.

    Fixes: ac0b4145d662 ("btrfs: scrub: Don't use inode pages for device replace")
    Signed-off-by: Qu Wenruo
    Signed-off-by: David Sterba
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Qu Wenruo
     
  • [ Upstream commit 3578a7ecb69920efc3885dbd610e98c00dbdf5db ]

    Testing has uncovered a failure case that is not handled properly. In the
    event that a login fails and we are not able to recover on the spot, we
    return 0 from do_reset, preventing any error recovery code from being
    triggered. Additionally, the state is set to "probed" meaning that when we
    are able to trigger the error recovery, the driver always comes up in the
    probed state. To handle the case properly, we need to return a failure code
    here and set the adapter state to the state that we entered the reset in
    indicating the state that we would like to come out of the recovery reset
    in.

    Signed-off-by: John Allen
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    John Allen
     
  • [ Upstream commit c133459765fae249ba482f62e12f987aec4376f0 ]

    CC [M] drivers/net/ethernet/freescale/fman/fman.o
    In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
    ../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
    ../include/linux/fsl/guts.h:165:2: error: implicit declaration of function 'clrsetbits_be32' [-Werror=implicit-function-declaration]
    clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
    ^~~~~~~~~~~~~~~

    Signed-off-by: Randy Dunlap
    Cc: Madalin Bucur
    Cc: netdev@vger.kernel.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     
  • [ Upstream commit 916c5e1413be058d1c1f6e502db350df890730ce ]

    The netvsc device may need to fallback to running in single queue
    mode if host side only wants to support single queue.

    Recent change for handling mtu broke this in setup logic.

    Reported-by: Dan Carpenter
    Fixes: 3ffe64f1a641 ("hv_netvsc: split sub-channel setup into async and sync")
    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stephen Hemminger