24 Aug, 2018

40 commits

  • [ 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
     
  • [ Upstream commit 7f073d011f93e92d4d225526b9ab6b8b0bbd6613 ]

    The bo array has req->nr_buffers elements so the > should be >= so we
    don't read beyond the end of the array.

    Fixes: a1606a9596e5 ("drm/nouveau: new gem pushbuf interface, bump to 0.0.16")
    Signed-off-by: Dan Carpenter
    Signed-off-by: Ben Skeggs
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • [ Upstream commit c29e9da56bebb4c2c794e871b0dc0298bbf08142 ]

    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference
    a bit later in the code.

    This is detected by Coccinelle semantic patch.

    @@
    expression pdev, res, n, t, e, e1, e2;
    @@

    res = platform_get_resource(pdev, t, n);
    + if (!res)
    + return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap_nocache(e1, res->start, e2);

    Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
    Signed-off-by: Wei Yongjun
    Reviewed-by: Ray Jui
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Wei Yongjun
     
  • [ Upstream commit f90a21c898db58eaea14b8ad7e9af3b9e15e5f8a ]

    The > comparisons should be >= or else we read beyond the end of the
    pinctrl->functions[] array.

    Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
    Signed-off-by: Dan Carpenter
    Reviewed-by: Ray Jui
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • [ Upstream commit 0084a786ca8c84b443f67c4a697b4f2552761650 ]

    The .gpio_set_direction() callback was setting inverted direction
    for SoCs older than the JZ4770, this restores the correct behaviour.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Paul Cercueil
     
  • [ Upstream commit a69258f7aa2623e0930212f09c586fd06674ad79 ]

    After fixing the way DCTCP tracking delayed ACKs, the delayed-ACK
    related callbacks are no longer needed

    Signed-off-by: Yuchung Cheng
    Signed-off-by: Eric Dumazet
    Acked-by: Neal Cardwell
    Acked-by: Lawrence Brakmo
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Yuchung Cheng
     
  • [ Upstream commit 5fc853cc01c68f84984ecc2d5fd777ecad78240f ]

    We accidentally left out the error handling for kstrtoul().

    Fixes: a520030e326a ("qlcnic: Implement flash sysfs callback for 83xx adapter")
    Signed-off-by: Dan Carpenter
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • [ Upstream commit 993675a3100b16a4c80dfd70cbcde8ea7127b31d ]

    If variable length link layer headers result in a packet shorter
    than dev->hard_header_len, reset the network header offset. Else
    skb->mac_len may exceed skb->len after skb_mac_reset_len.

    packet_sendmsg_spkt already has similar logic.

    Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Willem de Bruijn
     
  • [ Upstream commit 6d79a7b424a5630a6fcab31fd7c38af4ea9c9a0f ]

    Suppress warnings for systems that do not recognize LFS_*.

    getconf: no such configuration parameter `LFS_CFLAGS'
    getconf: no such configuration parameter `LFS_LDFLAGS'
    getconf: no such configuration parameter `LFS_LIBS'

    Fixes: d7f14c66c273 ("kbuild: Enable Large File Support for hostprogs")
    Reported-by: Chen Feng
    Signed-off-by: Masahiro Yamada
    Acked-by: Uwe Kleine-König
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • [ Upstream commit 8b247a92ebd0cda7dec49a6f771d9c4950f3d3ad ]

    The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS.
    Fix this.

    Signed-off-by: Laura Abbott
    Acked-by: Jiri Olsa
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Laura Abbott
     
  • [ Upstream commit d14c780c11fbc10f66c43e7b64eefe87ca442bd3 ]

    This change makes it so that we are much more explicit about the ordering
    of updates to the receive address register (RAR) table. Prior to this patch
    I believe we may have been updating the table while entries were still
    active, or possibly allowing for reordering of things since we weren't
    explicitly flushing writes to either the lower or upper portion of the
    register prior to accessing the other half.

    Signed-off-by: Alexander Duyck
    Reviewed-by: Shannon Nelson
    Tested-by: Andrew Bowers
    Signed-off-by: Jeff Kirsher
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Alexander Duyck
     
  • [ Upstream commit 923847413f7316b5ced3491769b3fefa6c56a79a ]

    The AM3517 has a different OTG controller location than the OMAP3,
    which is included from omap3.dtsi. This results in a hwmod error.
    Since the AM3517 has a different OTG controller address, this patch
    disabes one that is isn't available.

    Signed-off-by: Adam Ford
    Signed-off-by: Tony Lindgren
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Adam Ford
     
  • [ Upstream commit 2f8b5b21830aea95989a6e67d8a971297272a086 ]

    Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
    ICIALLU) when branch hardening is enabled for kernel.

    On GP devices OMAP5/DRA7, there is no possibility to update secure
    side since "secure world" is ROM and there are no override mechanisms
    possible. On HS devices, appropriate PPA should do the workarounds as
    well.

    However, the configuration is only done for secondary core, since it is
    expected that firmware/bootloader will have enabled the required
    configuration for the primary boot core (note: bootloaders typically
    will NOT enable secondary processors, since it has no need to do so).

    Signed-off-by: Nishanth Menon
    Signed-off-by: Tony Lindgren
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Nishanth Menon
     
  • [ Upstream commit b4c7e2bd2eb4764afe3af9409ff3b1b87116fa30 ]

    Dynamic ftrace requires modifying the code segments that are usually
    set to read-only. To do this, a per arch function is called both before
    and after the ftrace modifications are performed. The "before" function
    will set kernel code text to read-write to allow for ftrace to make the
    modifications, and the "after" function will set the kernel code text
    back to "read-only" to keep the kernel code text protected.

    The issue happens when dynamic ftrace is tested at boot up. The test is
    done before the kernel code text has been set to read-only. But the
    "before" and "after" calls are still performed. The "after" call will
    change the kernel code text to read-only prematurely, and other boot
    code that expects this code to be read-write will fail.

    The solution is to add a variable that is set when the kernel code text
    is expected to be converted to read-only, and make the ftrace "before"
    and "after" calls do nothing if that variable is not yet set. This is
    similar to the x86 solution from commit 162396309745 ("ftrace, x86:
    make kernel text writable only for conversions").

    Link: http://lkml.kernel.org/r/20180620212906.24b7b66e@vmware.local.home

    Reported-by: Stefan Agner
    Tested-by: Stefan Agner
    Signed-off-by: Steven Rostedt (VMware)
    Signed-off-by: Russell King
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Steven Rostedt (VMware)
     
  • [ Upstream commit d63c46734c545ad0488761059004a65c46efdde3 ]

    Fix memory leak in the error path of mlx5_ib_create_srq() by making sure
    to free the allocated srq.

    Fixes: c2b37f76485f ("IB/mlx5: Fix integer overflows in mlx5_ib_create_srq")
    Signed-off-by: Kamal Heib
    Acked-by: Leon Romanovsky
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kamal Heib
     
  • [ Upstream commit ee6581ceba7f8314b81b2f2a81f1cf3f67c679e2 ]

    Incremental patch to fix the unchecked dereference in acpi_nfit_ctl.
    Reported by Dan Carpenter:

    "acpi/nfit: fix cmd_rc for acpi_nfit_ctl to
    always return a value" from Jun 28, 2018, leads to the following
    Smatch complaint:

    drivers/acpi/nfit/core.c:578 acpi_nfit_ctl()
    warn: variable dereferenced before check 'cmd_rc' (see line 411)

    drivers/acpi/nfit/core.c
    410
    411 *cmd_rc = -EINVAL;
    ^^^^^^^^^^^^^^^^^^
    Patch adds unchecked dereference.

    Fixes: c1985cefd844 ("acpi/nfit: fix cmd_rc for acpi_nfit_ctl to always return a value")

    Signed-off-by: Dave Jiang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dave Jiang
     
  • [ Upstream commit db0ba84c04ef2cf293aaada5ae97531127844d9d ]

    The dictionaries are attached to the parameter tuple that steals the
    references and takes care of releasing them when appropriate. The code
    should not decrement the reference counts explicitly. E.g. if libpython
    has been built with reference debugging enabled, the superfluous DECREFs
    will trigger this error when running perf script:

    Fatal Python error: Objects/tupleobject.c:238 object at
    0x7f10f2041b40 has negative ref count -1
    Aborted (core dumped)

    If the reference debugging is not enabled, the superfluous DECREFs might
    cause the dict objects to be silently released while they are still in
    use. This may trigger various other assertions or just cause perf
    crashes and/or weird and unexpected data changes in the stored Python
    objects.

    Signed-off-by: Janne Huttunen
    Acked-by: Jiri Olsa
    Acked-by: Namhyung Kim
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: Jaroslav Skarvada
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1531133990-17485-1-git-send-email-janne.huttunen@nokia.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Janne Huttunen
     
  • [ Upstream commit a09603f851045b031e990d2d663958ccb49db525 ]

    We are getting following warnings on gcc8 that break compilation:

    $ make
    CC jvmti/jvmti_agent.o
    jvmti/jvmti_agent.c: In function ‘jvmti_open’:
    jvmti/jvmti_agent.c:252:35: error: ‘/jit-’ directive output may be truncated \
    writing 5 bytes into a region of size between 1 and 4096 [-Werror=format-truncation=]
    snprintf(dump_path, PATH_MAX, "%s/jit-%i.dump", jit_path, getpid());

    There's no point in checking the result of snprintf call in
    jvmti_open, the following open call will fail in case the
    name is mangled or too long.

    Using tools/lib/ function scnprintf that touches the return value from
    the snprintf() calls and thus get rid of those warnings.

    $ make DEBUG=1
    CC arch/x86/util/perf_regs.o
    arch/x86/util/perf_regs.c: In function ‘arch_sdt_arg_parse_op’:
    arch/x86/util/perf_regs.c:229:4: error: ‘strncpy’ output truncated before terminating nul
    copying 2 bytes from a string of the same length [-Werror=stringop-truncation]
    strncpy(prefix, "+0", 2);
    ^~~~~~~~~~~~~~~~~~~~~~~~

    Using scnprintf instead of the strncpy (which we know is safe in here)
    to get rid of that warning.

    Signed-off-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: David Ahern
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20180702134202.17745-1-jolsa@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jiri Olsa
     
  • [ Upstream commit f6432b9f65001651412dbc3589d251534822d4ab ]

    Like system(), popen() calls /bin/sh, which may/may not be bash.

    Script when run on dash and encounters the line, yields:

    exit: Illegal number: -1

    checkbashisms report on script content:

    possible bashism (exit|return with negative status code):
    exit -1

    Remove the bashism and use the more portable non-zero failure
    status code 1.

    Signed-off-by: Kim Phillips
    Cc: Alexander Shishkin
    Cc: Hendrik Brueckner
    Cc: Jiri Olsa
    Cc: Michael Petlan
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Cc: Sandipan Das
    Cc: Thomas Richter
    Link: http://lkml.kernel.org/r/20180629124652.8d0af7e2281fd3fd8262cacc@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kim Phillips
     
  • [ Upstream commit a3440d0d2f57f7ba102fc332086961cf261180af ]

    In case of iSCSI offload BFS environment, MFW requires to mark virtual
    link based upon qedi load status.

    Signed-off-by: Manish Rangankar
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Manish Rangankar
     
  • [ Upstream commit 6ac174756dfc9884f08b23af840ca911155f5578 ]

    Need to notify firmware when driver is loaded and unloaded.

    Signed-off-by: Saurav Kashyap
    Signed-off-by: Chad Dupuis
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Saurav Kashyap
     
  • [ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]

    Fix bug in the error code path when bnxt_request_irq() returns failure.
    bnxt_disable_napi() should not be called in this error path because
    NAPI has not been enabled yet.

    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Vikas Gupta
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Vikas Gupta
     
  • [ Upstream commit 78f058a4aa0f2280dc4d45d2c4a95728398ef857 ]

    The current code returns -ENOMEM and does not bother to set the output
    parameters to 0 when no rings are available. Some callers, such as
    bnxt_get_channels() will display garbage ring numbers when that happens.
    Fix it by always setting the output parameters.

    Fixes: 6e6c5a57fbe1 ("bnxt_en: Modify bnxt_get_max_rings() to support shared or non shared rings.")
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Chan
     
  • [ Upstream commit 07f4fde53d12eb8d921b465bb298e964e0bdc38c ]

    If there aren't enough RX rings available, the driver will attempt to
    use a single RX ring without the aggregation ring. If that also
    fails, the BNXT_FLAG_AGG_RINGS flag is cleared but the other ring
    parameters are not set consistently to reflect that. If more RX
    rings become available at the next open, the RX rings will be in
    an inconsistent state and may crash when freeing the RX rings.

    Fix it by restoring the BNXT_FLAG_AGG_RINGS if not enough RX rings are
    available to run without aggregation rings.

    Fixes: bdbd1eb59c56 ("bnxt_en: Handle no aggregation ring gracefully.")
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Chan
     
  • [ Upstream commit e8708786d4fe21c043d38d760f768949a3d71185 ]

    This is used in configs lacking hardware atomics to emulate atomic r-m-w
    for user space, implemented by disabling preemption in kernel.

    However there are issues in current implementation:

    1. Process not terminated if invalid user pointer passed:
    i.e. __get_user() failed.

    2. The reason for this patch was __put_user() failure not being handled
    either, specifically for the COW break scenario.
    The zero page is initially wired up and read from __get_user()
    succeeds. A subsequent write by __put_user() induces a
    Protection Violation, but COW can't finish as Linux page fault
    handler is disabled due to preempt disable.
    And what's worse is we silently return the stale value to user space.
    Fix this specific case by re-enabling preemption and explicitly
    fixing up the fault and retrying the whole sequence over.

    Cc: Max Filippov
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Alexey Brodkin
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Vineet Gupta
    [vgupta: rewrote the changelog]
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • [ Upstream commit 2045cdfa1b40d66f126f3fd05604fc7c754f0022 ]

    Loading the nf_conntrack module with doubled hashsize parameter, i.e.
    modprobe nf_conntrack hashsize=12345 hashsize=12345
    causes NULL-ptr deref.

    If 'hashsize' specified twice, the nf_conntrack_set_hashsize() function
    will be called also twice.
    The first nf_conntrack_set_hashsize() call will set the
    'nf_conntrack_htable_size' variable:

    nf_conntrack_set_hashsize()
    ...
    /* On boot, we can set this without any fancy locking. */
    if (!nf_conntrack_htable_size)
    return param_set_uint(val, kp);

    But on the second invocation, the nf_conntrack_htable_size is already set,
    so the nf_conntrack_set_hashsize() will take a different path and call
    the nf_conntrack_hash_resize() function. Which will crash on the attempt
    to dereference 'nf_conntrack_hash' pointer:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    RIP: 0010:nf_conntrack_hash_resize+0x255/0x490 [nf_conntrack]
    Call Trace:
    nf_conntrack_set_hashsize+0xcd/0x100 [nf_conntrack]
    parse_args+0x1f9/0x5a0
    load_module+0x1281/0x1a50
    __se_sys_finit_module+0xbe/0xf0
    do_syscall_64+0x7c/0x390
    entry_SYSCALL_64_after_hwframe+0x49/0xbe

    Fix this, by checking !nf_conntrack_hash instead of
    !nf_conntrack_htable_size. nf_conntrack_hash will be initialized only
    after the module loaded, so the second invocation of the
    nf_conntrack_set_hashsize() won't crash, it will just reinitialize
    nf_conntrack_htable_size again.

    Signed-off-by: Andrey Ryabinin
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andrey Ryabinin
     
  • [ Upstream commit 21d5e078192d244df3d6049f9464fff2f72cfd68 ]

    iptables-nft never requests these, but make this explicitly illegal.
    If it were quested, kernel could oops as ->eval is NULL, furthermore,
    the builtin targets have no owning module so its possible to rmmod
    eb/ip/ip6_tables module even if they would be loaded.

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Florian Westphal
     
  • [ Upstream commit 92298c1cd8e8a6b56322b602ad72b54e6237631d ]

    Add the missing locks to the IRQ enable/disable paths, and fix a comment
    in the interrupt handler: reading the ISR clears down the status bits,
    but does not reset the interrupt so it can signal again. That seems to
    require a write.

    Signed-off-by: Russell King
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Russell King