commit 893af1c79e42e53af0da22165b46eea135af0613
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 9 17:52:35 2019 +0200

    Linux 4.19.66

commit 48fcdaba7b0d31e59f01ce96b4f53e8149787d1a
Author: Lukas Wunner <lukas@wunner.de>
Date:   Wed Jul 3 12:29:31 2019 +0200

    spi: bcm2835: Fix 3-wire mode if DMA is enabled
    
    commit 8d8bef50365847134b51c1ec46786bc2873e4e47 upstream.
    
    Commit 6935224da248 ("spi: bcm2835: enable support of 3-wire mode")
    added 3-wire support to the BCM2835 SPI driver by setting the REN bit
    (Read Enable) in the CS register when receiving data.  The REN bit puts
    the transmitter in high-impedance state.  The driver recognizes that
    data is to be received by checking whether the rx_buf of a transfer is
    non-NULL.
    
    Commit 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers
    meeting certain conditions") subsequently broke 3-wire support because
    it set the SPI_MASTER_MUST_RX flag which causes spi_map_msg() to replace
    rx_buf with a dummy buffer if it is NULL.  As a result, rx_buf is
    *always* non-NULL if DMA is enabled.
    
    Reinstate 3-wire support by not only checking whether rx_buf is non-NULL,
    but also checking that it is not the dummy buffer.
    
    Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions")
    Reported-by: Nuno Sá <nuno.sa@analog.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org # v4.2+
    Cc: Martin Sperl <kernel@martin.sperl.org>
    Acked-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/328318841455e505370ef8ecad97b646c033dc8a.1562148527.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebda41dd170fd160e44f97d7a2a215ae9d0009b1
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Jun 10 09:08:27 2019 -0700

    cgroup: Fix css_task_iter_advance_css_set() cset skip condition
    
    commit c596687a008b579c503afb7a64fcacc7270fae9e upstream.
    
    While adding handling for dying task group leaders c03cd7738a83
    ("cgroup: Include dying leaders with live threads in PROCS
    iterations") added an inverted cset skip condition to
    css_task_iter_advance_css_set().  It should skip cset if it's
    completely empty but was incorrectly testing for the inverse condition
    for the dying_tasks list.  Fix it.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: c03cd7738a83 ("cgroup: Include dying leaders with live threads in PROCS iterations")
    Reported-by: syzbot+d4bba5ccd4f9a2a68681@syzkaller.appspotmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a9abd277819058b6beafa40bfe0a56f19edec38
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Jun 5 09:54:34 2019 -0700

    cgroup: css_task_iter_skip()'d iterators must be advanced before accessed
    
    commit cee0c33c546a93957a52ae9ab6bebadbee765ec5 upstream.
    
    b636fd38dc40 ("cgroup: Implement css_task_iter_skip()") introduced
    css_task_iter_skip() which is used to fix task iterations skipping
    dying threadgroup leaders with live threads.  Skipping is implemented
    as a subportion of full advancing but css_task_iter_next() forgot to
    fully advance a skipped iterator before determining the next task to
    visit causing it to return invalid task pointers.
    
    Fix it by making css_task_iter_next() fully advance the iterator if it
    has been skipped since the previous iteration.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: syzbot
    Link: http://lkml.kernel.org/r/00000000000097025d058a7fd785@google.com
    Fixes: b636fd38dc40 ("cgroup: Implement css_task_iter_skip()")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4340d175b89896d069c1e875f5b98c80a408f680
Author: Tejun Heo <tj@kernel.org>
Date:   Fri May 31 10:38:58 2019 -0700

    cgroup: Include dying leaders with live threads in PROCS iterations
    
    commit c03cd7738a83b13739f00546166969342c8ff014 upstream.
    
    CSS_TASK_ITER_PROCS currently iterates live group leaders; however,
    this means that a process with dying leader and live threads will be
    skipped.  IOW, cgroup.procs might be empty while cgroup.threads isn't,
    which is confusing to say the least.
    
    Fix it by making cset track dying tasks and include dying leaders with
    live threads in PROCS iteration.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-and-tested-by: Topi Miettinen <toiwoton@gmail.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 370b9e6399da09fe10005fe455878b356de7b85f
Author: Tejun Heo <tj@kernel.org>
Date:   Fri May 31 10:38:58 2019 -0700

    cgroup: Implement css_task_iter_skip()
    
    commit b636fd38dc40113f853337a7d2a6885ad23b8811 upstream.
    
    When a task is moved out of a cset, task iterators pointing to the
    task are advanced using the normal css_task_iter_advance() call.  This
    is fine but we'll be tracking dying tasks on csets and thus moving
    tasks from cset->tasks to (to be added) cset->dying_tasks.  When we
    remove a task from cset->tasks, if we advance the iterators, they may
    move over to the next cset before we had the chance to add the task
    back on the dying list, which can allow the task to escape iteration.
    
    This patch separates out skipping from advancing.  Skipping only moves
    the affected iterators to the next pointer rather than fully advancing
    it and the following advancing will recognize that the cursor has
    already been moved forward and do the rest of advancing.  This ensures
    that when a task moves from one list to another in its cset, as long
    as it moves in the right direction, it's always visible to iteration.
    
    This doesn't cause any visible behavior changes.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7528e95b7519d24027a4362e2a05a12d4747586f
Author: Tejun Heo <tj@kernel.org>
Date:   Fri May 31 10:38:57 2019 -0700

    cgroup: Call cgroup_release() before __exit_signal()
    
    commit 6b115bf58e6f013ca75e7115aabcbd56c20ff31d upstream.
    
    cgroup_release() calls cgroup_subsys->release() which is used by the
    pids controller to uncharge its pid.  We want to use it to manage
    iteration of dying tasks which requires putting it before
    __unhash_process().  Move cgroup_release() above __exit_signal().
    While this makes it uncharge before the pid is freed, pid is RCU freed
    anyway and the window is very narrow.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6e9bcef12ca2e2119f999d38dbca5147b06bc14
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jul 30 21:25:20 2019 +0200

    compat_ioctl: pppoe: fix PPPOEIOCSFWD handling
    
    [ Upstream commit 055d88242a6046a1ceac3167290f054c72571cd9 ]
    
    Support for handling the PPPOEIOCSFWD ioctl in compat mode was added in
    linux-2.5.69 along with hundreds of other commands, but was always broken
    sincen only the structure is compatible, but the command number is not,
    due to the size being sizeof(size_t), or at first sizeof(sizeof((struct
    sockaddr_pppox)), which is different on 64-bit architectures.
    
    Guillaume Nault adds:
    
      And the implementation was broken until 2016 (see 29e73269aa4d ("pppoe:
      fix reference counting in PPPoE proxy")), and nobody ever noticed. I
      should probably have removed this ioctl entirely instead of fixing it.
      Clearly, it has never been used.
    
    Fix it by adding a compat_ioctl handler for all pppoe variants that
    translates the command number and then calls the regular ioctl function.
    
    All other ioctl commands handled by pppoe are compatible between 32-bit
    and 64-bit, and require compat_ptr() conversion.
    
    This should apply to all stable kernels.
    
    Acked-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 473430ed61174498db9fcac8bbfee122657d3933
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Jul 27 12:45:10 2019 +0200

    r8169: don't use MSI before RTL8168d
    
    [ Upstream commit 003bd5b4a7b4a94b501e3a1e2e7c9df6b2a94ed4 ]
    
    It was reported that after resuming from suspend network fails with
    error "do_IRQ: 3.38 No irq handler for vector", see [0]. Enabling WoL
    can work around the issue, but the only actual fix is to disable MSI.
    So let's mimic the behavior of the vendor driver and disable MSI on
    all chip versions before RTL8168d.
    
    [0] https://bugzilla.kernel.org/show_bug.cgi?id=204079
    
    Fixes: 6c6aa15fdea5 ("r8169: improve interrupt handling")
    Reported-by: Dušan Dragić <dragic.dusan@gmail.com>
    Tested-by: Dušan Dragić <dragic.dusan@gmail.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ccf47265e4cb7fd13d339ee20a84bdbdbd466ef
Author: Ariel Levkovich <lariel@mellanox.com>
Date:   Sat Jul 6 18:06:15 2019 +0300

    net/mlx5e: Prevent encap flow counter update async to user query
    
    [ Upstream commit 90bb769291161cf25a818d69cf608c181654473e ]
    
    This patch prevents a race between user invoked cached counters
    query and a neighbor last usage updater.
    
    The cached flow counter stats can be queried by calling
    "mlx5_fc_query_cached" which provides the number of bytes and
    packets that passed via this flow since the last time this counter
    was queried.
    It does so by reducting the last saved stats from the current, cached
    stats and then updating the last saved stats with the cached stats.
    It also provide the lastuse value for that flow.
    
    Since "mlx5e_tc_update_neigh_used_value" needs to retrieve the
    last usage time of encapsulation flows, it calls the flow counter
    query method periodically and async to user queries of the flow counter
    using cls_flower.
    This call is causing the driver to update the last reported bytes and
    packets from the cache and therefore, future user queries of the flow
    stats will return lower than expected number for bytes and packets
    since the last saved stats in the driver was updated async to the last
    saved stats in cls_flower.
    
    This causes wrong stats presentation of encapsulation flows to user.
    
    Since the neighbor usage updater only needs the lastuse stats from the
    cached counter, the fix is to use a dedicated lastuse query call that
    returns the lastuse value without synching between the cached stats and
    the last saved stats.
    
    Fixes: f6dfb4c3f216 ("net/mlx5e: Update neighbour 'used' state using HW flow rules counters")
    Signed-off-by: Ariel Levkovich <lariel@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd84a10792f08d3d0cc1cbeed07634e454fe9abd
Author: Edward Srouji <edwards@mellanox.com>
Date:   Tue Jul 23 10:12:55 2019 +0300

    net/mlx5: Fix modify_cq_in alignment
    
    [ Upstream commit 7a32f2962c56d9d8a836b4469855caeee8766bd4 ]
    
    Fix modify_cq_in alignment to match the device specification.
    After this fix the 'cq_umem_valid' field will be in the right offset.
    
    Cc: <stable@vger.kernel.org> # 4.19
    Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID bits")
    Signed-off-by: Edward Srouji <edwards@mellanox.com>
    Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f378724e10ced69c5e55db2e23ad350ede76f174
Author: Alexis Bauvin <abauvin@scaleway.com>
Date:   Tue Jul 23 16:23:01 2019 +0200

    tun: mark small packets as owned by the tap sock
    
    [ Upstream commit 4b663366246be1d1d4b1b8b01245b2e88ad9e706 ]
    
    - v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size
    
    Small packets going out of a tap device go through an optimized code
    path that uses build_skb() rather than sock_alloc_send_pskb(). The
    latter calls skb_set_owner_w(), but the small packet code path does not.
    
    The net effect is that small packets are not owned by the userland
    application's socket (e.g. QEMU), while large packets are.
    This can be seen with a TCP session, where packets are not owned when
    the window size is small enough (around PAGE_SIZE), while they are once
    the window grows (note that this requires the host to support virtio
    tso for the guest to offload segmentation).
    All this leads to inconsistent behaviour in the kernel, especially on
    netfilter modules that uses sk->socket (e.g. xt_owner).
    
    Fixes: 66ccbc9c87c2 ("tap: use build_skb() for small packet")
    Signed-off-by: Alexis Bauvin <abauvin@scaleway.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5295d651548559e90245a5d744566af98d951df1
Author: Taras Kondratiuk <takondra@cisco.com>
Date:   Mon Jul 29 22:15:07 2019 +0000

    tipc: compat: allow tipc commands without arguments
    
    [ Upstream commit 4da5f0018eef4c0de31675b670c80e82e13e99d1 ]
    
    Commit 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
    broke older tipc tools that use compat interface (e.g. tipc-config from
    tipcutils package):
    
    % tipc-config -p
    operation not supported
    
    The commit started to reject TIPC netlink compat messages that do not
    have attributes. It is too restrictive because some of such messages are
    valid (they don't need any arguments):
    
    % grep 'tx none' include/uapi/linux/tipc_config.h
    #define  TIPC_CMD_NOOP              0x0000    /* tx none, rx none */
    #define  TIPC_CMD_GET_MEDIA_NAMES   0x0002    /* tx none, rx media_name(s) */
    #define  TIPC_CMD_GET_BEARER_NAMES  0x0003    /* tx none, rx bearer_name(s) */
    #define  TIPC_CMD_SHOW_PORTS        0x0006    /* tx none, rx ultra_string */
    #define  TIPC_CMD_GET_REMOTE_MNG    0x4003    /* tx none, rx unsigned */
    #define  TIPC_CMD_GET_MAX_PORTS     0x4004    /* tx none, rx unsigned */
    #define  TIPC_CMD_GET_NETID         0x400B    /* tx none, rx unsigned */
    #define  TIPC_CMD_NOT_NET_ADMIN     0xC001    /* tx none, rx none */
    
    This patch relaxes the original fix and rejects messages without
    arguments only if such arguments are expected by a command (reg_type is
    non zero).
    
    Fixes: 2753ca5d9009 ("tipc: fix uninit-value in tipc_nl_compat_doit")
    Cc: stable@vger.kernel.org
    Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaa34bd4f7b5e505c6c211cb906f6a2ce2242e4c
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Thu Jul 25 16:33:18 2019 +0300

    ocelot: Cancel delayed work before wq destruction
    
    [ Upstream commit c5d139697d5d9ecf9c7cd92d7d7838a173508900 ]
    
    Make sure the delayed work for stats update is not pending before
    wq destruction.
    This fixes the module unload path.
    The issue is there since day 1.
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd7f02fecac188f3363ef1d420b284c2239947e0
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Aug 5 12:00:55 2019 +0200

    NFC: nfcmrvl: fix gpio-handling regression
    
    [ Upstream commit c3953a3c2d3175d2f9f0304c9a1ba89e7743c5e4 ]
    
    Fix two reset-gpio sanity checks which were never converted to use
    gpio_is_valid(), and make sure to use -EINVAL to indicate a missing
    reset line also for the UART-driver module parameter and for the USB
    driver.
    
    This specifically prevents the UART and USB drivers from incidentally
    trying to request and use gpio 0, and also avoids triggering a WARN() in
    gpio_to_desc() during probe when no valid reset line has been specified.
    
    Fixes: e33a3f84f88f ("NFC: nfcmrvl: allow gpio 0 for reset signalling")
    Reported-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
    Tested-by: syzbot+cf35b76f35e068a1107f@syzkaller.appspotmail.com
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce58a3655121936ebf353db542315e3531233113
Author: Ursula Braun <ubraun@linux.ibm.com>
Date:   Fri Aug 2 10:16:38 2019 +0200

    net/smc: do not schedule tx_work in SMC_CLOSED state
    
    [ Upstream commit f9cedf1a9b1cdcfb0c52edb391d01771e43994a4 ]
    
    The setsockopts options TCP_NODELAY and TCP_CORK may schedule the
    tx worker. Make sure the socket is not yet moved into SMC_CLOSED
    state (for instance by a shutdown SHUT_RDWR call).
    
    Reported-by: syzbot+92209502e7aab127c75f@syzkaller.appspotmail.com
    Reported-by: syzbot+b972214bb803a343f4fe@syzkaller.appspotmail.com
    Fixes: 01d2f7e2cdd31 ("net/smc: sockopts TCP_NODELAY and TCP_CORK")
    Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
    Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51d240a144a5742977b4a421ea42b7da5bf1439c
Author: Dmytro Linkin <dmitrolin@mellanox.com>
Date:   Thu Aug 1 13:02:51 2019 +0000

    net: sched: use temporary variable for actions indexes
    
    [ Upstream commit 7be8ef2cdbfe41a2e524b7c6cc3f8e6cfaa906e4 ]
    
    Currently init call of all actions (except ipt) init their 'parm'
    structure as a direct pointer to nla data in skb. This leads to race
    condition when some of the filter actions were initialized successfully
    (and were assigned with idr action index that was written directly
    into nla data), but then were deleted and retried (due to following
    action module missing or classifier-initiated retry), in which case
    action init code tries to insert action to idr with index that was
    assigned on previous iteration. During retry the index can be reused
    by another action that was inserted concurrently, which causes
    unintended action sharing between filters.
    To fix described race condition, save action idr index to temporary
    stack-allocated variable instead on nla data.
    
    Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
    Signed-off-by: Dmytro Linkin <dmitrolin@mellanox.com>
    Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb20f74135df76ab386afa3bb1ad1af6b995f697
Author: Roman Mashak <mrv@mojatatu.com>
Date:   Fri Aug 2 15:16:46 2019 -0400

    net sched: update vlan action for batched events operations
    
    [ Upstream commit b35475c5491a14c8ce7a5046ef7bcda8a860581a ]
    
    Add get_fill_size() routine used to calculate the action size
    when building a batch of events.
    
    Fixes: c7e2b9689 ("sched: introduce vlan action")
    Signed-off-by: Roman Mashak <mrv@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d82dc254b9670068fe8c2652553eb144cfa26399
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Mon Jul 29 16:24:33 2019 +0800

    net: sched: Fix a possible null-pointer dereference in dequeue_func()
    
    [ Upstream commit 051c7b39be4a91f6b7d8c4548444e4b850f1f56c ]
    
    In dequeue_func(), there is an if statement on line 74 to check whether
    skb is NULL:
        if (skb)
    
    When skb is NULL, it is used on line 77:
        prefetch(&skb->end);
    
    Thus, a possible null-pointer dereference may occur.
    
    To fix this bug, skb->end is used when skb is not NULL.
    
    This bug is found by a static analysis tool STCheck written by us.
    
    Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM")
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44b96a38c2b5dd6e67039898201fdbcbaa4974ae
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Thu Jul 25 12:07:12 2019 -0600

    net: qualcomm: rmnet: Fix incorrect UL checksum offload logic
    
    [ Upstream commit a7cf3d24ee6081930feb4c830a7f6f16ebe31c49 ]
    
    The udp_ip4_ind bit is set only for IPv4 UDP non-fragmented packets
    so that the hardware can flip the checksum to 0xFFFF if the computed
    checksum is 0 per RFC768.
    
    However, this bit had to be set for IPv6 UDP non fragmented packets
    as well per hardware requirements. Otherwise, IPv6 UDP packets
    with computed checksum as 0 were transmitted by hardware and were
    dropped in the network.
    
    In addition to setting this bit for IPv6 UDP, the field is also
    appropriately renamed to udp_ind as part of this change.
    
    Fixes: 5eb5f8608ef1 ("net: qualcomm: rmnet: Add support for TX checksum offload")
    Cc: Sean Tranchetti <stranche@codeaurora.org>
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8b05980c4bf7abfe9a016c34f8bf3bb5396cbfb
Author: René van Dorst <opensource@vdorst.com>
Date:   Sat Jul 27 11:40:11 2019 +0200

    net: phylink: Fix flow control for fixed-link
    
    [ Upstream commit 8aace4f3eba2a3ceb431e18683ea0e1ecbade5cd ]
    
    In phylink_parse_fixedlink() the pl->link_config.advertising bits are AND
    with pl->supported, pl->supported is zeroed and only the speed/duplex
    modes and MII bits are set.
    So pl->link_config.advertising always loses the flow control/pause bits.
    
    By setting Pause and Asym_Pause bits in pl->supported, the flow control
    work again when devicetree "pause" is set in fixes-link node and the MAC
    advertise that is supports pause.
    
    Results with this patch.
    
    Legend:
    - DT = 'Pause' is set in the fixed-link in devicetree.
    - validate() = ‘Yes’ means phylink_set(mask, Pause) is set in the
      validate().
    - flow = results reported my link is Up line.
    
    +-----+------------+-------+
    | DT  | validate() | flow  |
    +-----+------------+-------+
    | Yes | Yes        | rx/tx |
    | No  | Yes        | off   |
    | Yes | No         | off   |
    +-----+------------+-------+
    
    Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
    Signed-off-by: René van Dorst <opensource@vdorst.com>
    Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dddd08b571d73e9acb87b4b7fff763ba3e6d6cd
Author: Mark Zhang <markz@mellanox.com>
Date:   Tue Jul 9 05:37:12 2019 +0300

    net/mlx5: Use reversed order when unregister devices
    
    [ Upstream commit 08aa5e7da6bce1a1963f63cf32c2e7ad434ad578 ]
    
    When lag is active, which is controlled by the bonded mlx5e netdev, mlx5
    interface unregestering must happen in the reverse order where rdma is
    unregistered (unloaded) first, to guarantee all references to the lag
    context in hardware is removed, then remove mlx5e netdev interface which
    will cleanup the lag context from hardware.
    
    Without this fix during destroy of LAG interface, we observed following
    errors:
     * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
       status bad parameter(0x3), syndrome (0xe4ac33)
     * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed,
       status bad parameter(0x3), syndrome (0xa5aee8).
    
    Fixes: a31208b1e11d ("net/mlx5_core: New init and exit flow for mlx5_core")
    Reviewed-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Mark Zhang <markz@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 858f82c63667281719805a1b03a1405f14ac0269
Author: Qian Cai <cai@lca.pw>
Date:   Thu Aug 1 09:52:54 2019 -0400

    net/mlx5e: always initialize frag->last_in_page
    
    [ Upstream commit 60d60c8fbd8d1acf25b041ecd72ae4fa16e9405b ]
    
    The commit 069d11465a80 ("net/mlx5e: RX, Enhance legacy Receive Queue
    memory scheme") introduced an undefined behaviour below due to
    "frag->last_in_page" is only initialized in mlx5e_init_frags_partition()
    when,
    
    if (next_frag.offset + frag_info[f].frag_stride > PAGE_SIZE)
    
    or after bailed out the loop,
    
    for (i = 0; i < mlx5_wq_cyc_get_size(&rq->wqe.wq); i++)
    
    As the result, there could be some "frag" have uninitialized
    value of "last_in_page".
    
    Later, get_frag() obtains those "frag" and check "frag->last_in_page" in
    mlx5e_put_rx_frag() and triggers the error during boot. Fix it by always
    initializing "frag->last_in_page" to "false" in
    mlx5e_init_frags_partition().
    
    UBSAN: Undefined behaviour in
    drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:325:12
    load of value 170 is not a valid value for type 'bool' (aka '_Bool')
    Call trace:
     dump_backtrace+0x0/0x264
     show_stack+0x20/0x2c
     dump_stack+0xb0/0x104
     __ubsan_handle_load_invalid_value+0x104/0x128
     mlx5e_handle_rx_cqe+0x8e8/0x12cc [mlx5_core]
     mlx5e_poll_rx_cq+0xca8/0x1a94 [mlx5_core]
     mlx5e_napi_poll+0x17c/0xa30 [mlx5_core]
     net_rx_action+0x248/0x940
     __do_softirq+0x350/0x7b8
     irq_exit+0x200/0x26c
     __handle_domain_irq+0xc8/0x128
     gic_handle_irq+0x138/0x228
     el1_irq+0xb8/0x140
     arch_cpu_idle+0x1a4/0x348
     do_idle+0x114/0x1b0
     cpu_startup_entry+0x24/0x28
     rest_init+0x1ac/0x1dc
     arch_call_rest_init+0x10/0x18
     start_kernel+0x4d4/0x57c
    
    Fixes: 069d11465a80 ("net/mlx5e: RX, Enhance legacy Receive Queue memory scheme")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edb7ad69c439cdb960d9f519233d8d9771e329b5
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Sun Jul 28 14:56:36 2019 +0200

    net: fix ifindex collision during namespace removal
    
    [ Upstream commit 55b40dbf0e76b4bfb9d8b3a16a0208640a9a45df ]
    
    Commit aca51397d014 ("netns: Fix arbitrary net_device-s corruptions
    on net_ns stop.") introduced a possibility to hit a BUG in case device
    is returning back to init_net and two following conditions are met:
    1) dev->ifindex value is used in a name of another "dev%d"
       device in init_net.
    2) dev->name is used by another device in init_net.
    
    Under real life circumstances this is hard to get. Therefore this has
    been present happily for over 10 years. To reproduce:
    
    $ ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 86:89:3f:86:61:29 brd ff:ff:ff:ff:ff:ff
    3: enp0s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    $ ip netns add ns1
    $ ip -n ns1 link add dummy1ns1 type dummy
    $ ip -n ns1 link add dummy2ns1 type dummy
    $ ip link set enp0s2 netns ns1
    $ ip -n ns1 link set enp0s2 name dummy0
    [  100.858894] virtio_net virtio0 dummy0: renamed from enp0s2
    $ ip link add dev4 type dummy
    $ ip -n ns1 a
    1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: dummy1ns1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 16:63:4c:38:3e:ff brd ff:ff:ff:ff:ff:ff
    3: dummy2ns1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether aa:9e:86:dd:6b:5d brd ff:ff:ff:ff:ff:ff
    4: dummy0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    $ ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 86:89:3f:86:61:29 brd ff:ff:ff:ff:ff:ff
    4: dev4: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 5a:e1:4a:b6:ec:f8 brd ff:ff:ff:ff:ff:ff
    $ ip netns del ns1
    [  158.717795] default_device_exit: failed to move dummy0 to init_net: -17
    [  158.719316] ------------[ cut here ]------------
    [  158.720591] kernel BUG at net/core/dev.c:9824!
    [  158.722260] invalid opcode: 0000 [#1] SMP KASAN PTI
    [  158.723728] CPU: 0 PID: 56 Comm: kworker/u2:1 Not tainted 5.3.0-rc1+ #18
    [  158.725422] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014
    [  158.727508] Workqueue: netns cleanup_net
    [  158.728915] RIP: 0010:default_device_exit.cold+0x1d/0x1f
    [  158.730683] Code: 84 e8 18 c9 3e fe 0f 0b e9 70 90 ff ff e8 36 e4 52 fe 89 d9 4c 89 e2 48 c7 c6 80 d6 25 84 48 c7 c7 20 c0 25 84 e8 f4 c8 3e
    [  158.736854] RSP: 0018:ffff8880347e7b90 EFLAGS: 00010282
    [  158.738752] RAX: 000000000000003b RBX: 00000000ffffffef RCX: 0000000000000000
    [  158.741369] RDX: 0000000000000000 RSI: ffffffff8128013d RDI: ffffed10068fcf64
    [  158.743418] RBP: ffff888033550170 R08: 000000000000003b R09: fffffbfff0b94b9c
    [  158.745626] R10: fffffbfff0b94b9b R11: ffffffff85ca5cdf R12: ffff888032f28000
    [  158.748405] R13: dffffc0000000000 R14: ffff8880335501b8 R15: 1ffff110068fcf72
    [  158.750638] FS:  0000000000000000(0000) GS:ffff888036000000(0000) knlGS:0000000000000000
    [  158.752944] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  158.755245] CR2: 00007fe8b45d21d0 CR3: 00000000340b4005 CR4: 0000000000360ef0
    [  158.757654] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  158.760012] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  158.762758] Call Trace:
    [  158.763882]  ? dev_change_net_namespace+0xbb0/0xbb0
    [  158.766148]  ? devlink_nl_cmd_set_doit+0x520/0x520
    [  158.768034]  ? dev_change_net_namespace+0xbb0/0xbb0
    [  158.769870]  ops_exit_list.isra.0+0xa8/0x150
    [  158.771544]  cleanup_net+0x446/0x8f0
    [  158.772945]  ? unregister_pernet_operations+0x4a0/0x4a0
    [  158.775294]  process_one_work+0xa1a/0x1740
    [  158.776896]  ? pwq_dec_nr_in_flight+0x310/0x310
    [  158.779143]  ? do_raw_spin_lock+0x11b/0x280
    [  158.780848]  worker_thread+0x9e/0x1060
    [  158.782500]  ? process_one_work+0x1740/0x1740
    [  158.784454]  kthread+0x31b/0x420
    [  158.786082]  ? __kthread_create_on_node+0x3f0/0x3f0
    [  158.788286]  ret_from_fork+0x3a/0x50
    [  158.789871] ---[ end trace defd6c657c71f936 ]---
    [  158.792273] RIP: 0010:default_device_exit.cold+0x1d/0x1f
    [  158.795478] Code: 84 e8 18 c9 3e fe 0f 0b e9 70 90 ff ff e8 36 e4 52 fe 89 d9 4c 89 e2 48 c7 c6 80 d6 25 84 48 c7 c7 20 c0 25 84 e8 f4 c8 3e
    [  158.804854] RSP: 0018:ffff8880347e7b90 EFLAGS: 00010282
    [  158.807865] RAX: 000000000000003b RBX: 00000000ffffffef RCX: 0000000000000000
    [  158.811794] RDX: 0000000000000000 RSI: ffffffff8128013d RDI: ffffed10068fcf64
    [  158.816652] RBP: ffff888033550170 R08: 000000000000003b R09: fffffbfff0b94b9c
    [  158.820930] R10: fffffbfff0b94b9b R11: ffffffff85ca5cdf R12: ffff888032f28000
    [  158.825113] R13: dffffc0000000000 R14: ffff8880335501b8 R15: 1ffff110068fcf72
    [  158.829899] FS:  0000000000000000(0000) GS:ffff888036000000(0000) knlGS:0000000000000000
    [  158.834923] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  158.838164] CR2: 00007fe8b45d21d0 CR3: 00000000340b4005 CR4: 0000000000360ef0
    [  158.841917] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  158.845149] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fix this by checking if a device with the same name exists in init_net
    and fallback to original code - dev%d to allocate name - in case it does.
    
    This was found using syzkaller.
    
    Fixes: aca51397d014 ("netns: Fix arbitrary net_device-s corruptions on net_ns stop.")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a19d4e34f092fdb74e39de0193627f16a38997b8
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Tue Jul 30 14:21:00 2019 +0300

    net: bridge: mcast: don't delete permanent entries when fast leave is enabled
    
    [ Upstream commit 5c725b6b65067909548ac9ca9bc777098ec9883d ]
    
    When permanent entries were introduced by the commit below, they were
    exempt from timing out and thus igmp leave wouldn't affect them unless
    fast leave was enabled on the port which was added before permanent
    entries existed. It shouldn't matter if fast leave is enabled or not
    if the user added a permanent entry it shouldn't be deleted on igmp
    leave.
    
    Before:
    $ echo 1 > /sys/class/net/eth4/brport/multicast_fast_leave
    $ bridge mdb add dev br0 port eth4 grp 229.1.1.1 permanent
    $ bridge mdb show
    dev br0 port eth4 grp 229.1.1.1 permanent
    
    < join and leave 229.1.1.1 on eth4 >
    
    $ bridge mdb show
    $
    
    After:
    $ echo 1 > /sys/class/net/eth4/brport/multicast_fast_leave
    $ bridge mdb add dev br0 port eth4 grp 229.1.1.1 permanent
    $ bridge mdb show
    dev br0 port eth4 grp 229.1.1.1 permanent
    
    < join and leave 229.1.1.1 on eth4 >
    
    $ bridge mdb show
    dev br0 port eth4 grp 229.1.1.1 permanent
    
    Fixes: ccb1c31a7a87 ("bridge: add flags to distinguish permanent mdb entires")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 639239be11ad95fab3266577e8d1efa1e8ec9672
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Mon Jul 29 12:28:41 2019 +0300

    net: bridge: delete local fdb on device init failure
    
    [ Upstream commit d7bae09fa008c6c9a489580db0a5a12063b97f97 ]
    
    On initialization failure we have to delete the local fdb which was
    inserted due to the default pvid creation. This problem has been present
    since the inception of default_pvid. Note that currently there are 2 cases:
    1) in br_dev_init() when br_multicast_init() fails
    2) if register_netdevice() fails after calling ndo_init()
    
    This patch takes care of both since br_vlan_flush() is called on both
    occasions. Also the new fdb delete would be a no-op on normal bridge
    device destruction since the local fdb would've been already flushed by
    br_dev_delete(). This is not an issue for ports since nbp_vlan_init() is
    called last when adding a port thus nothing can fail after it.
    
    Reported-by: syzbot+88533dc8b582309bf3ee@syzkaller.appspotmail.com
    Fixes: 5be5a2df40f0 ("bridge: Add filtering support for default_pvid")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3645a487373e2182bd9899a4fe3a2cbf2010e6e
Author: Matteo Croce <mcroce@redhat.com>
Date:   Sun Jul 28 02:46:45 2019 +0200

    mvpp2: refactor MTU change code
    
    [ Upstream commit 230bd958c2c846ee292aa38bc6b006296c24ca01 ]
    
    The MTU change code can call napi_disable() with the device already down,
    leading to a deadlock. Also, lot of code is duplicated unnecessarily.
    
    Rework mvpp2_change_mtu() to avoid the deadlock and remove duplicated code.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Matteo Croce <mcroce@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffab47bf69df0f340d56ded363bac09950ae2395
Author: Matteo Croce <mcroce@redhat.com>
Date:   Thu Aug 1 14:13:30 2019 +0200

    mvpp2: fix panic on module removal
    
    [ Upstream commit 944a83a2669ae8aa2c7664e79376ca7468eb0a2b ]
    
    mvpp2 uses a delayed workqueue to gather traffic statistics.
    On module removal the workqueue can be destroyed before calling
    cancel_delayed_work_sync() on its works.
    Fix it by moving the destroy_workqueue() call after mvpp2_port_remove().
    Also remove an unneeded call to flush_workqueue()
    
        # rmmod mvpp2
        [ 2743.311722] mvpp2 f4000000.ethernet eth1: phy link down 10gbase-kr/10Gbps/Full
        [ 2743.320063] mvpp2 f4000000.ethernet eth1: Link is Down
        [ 2743.572263] mvpp2 f4000000.ethernet eth2: phy link down sgmii/1Gbps/Full
        [ 2743.580076] mvpp2 f4000000.ethernet eth2: Link is Down
        [ 2744.102169] mvpp2 f2000000.ethernet eth0: phy link down 10gbase-kr/10Gbps/Full
        [ 2744.110441] mvpp2 f2000000.ethernet eth0: Link is Down
        [ 2744.115614] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
        [ 2744.115615] Mem abort info:
        [ 2744.115616]   ESR = 0x96000005
        [ 2744.115617]   Exception class = DABT (current EL), IL = 32 bits
        [ 2744.115618]   SET = 0, FnV = 0
        [ 2744.115619]   EA = 0, S1PTW = 0
        [ 2744.115620] Data abort info:
        [ 2744.115621]   ISV = 0, ISS = 0x00000005
        [ 2744.115622]   CM = 0, WnR = 0
        [ 2744.115624] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000422681000
        [ 2744.115626] [0000000000000000] pgd=0000000000000000, pud=0000000000000000
        [ 2744.115630] Internal error: Oops: 96000005 [#1] SMP
        [ 2744.115632] Modules linked in: mvpp2(-) algif_hash af_alg nls_iso8859_1 nls_cp437 vfat fat xhci_plat_hcd m25p80 spi_nor xhci_hcd mtd usbcore i2c_mv64xxx sfp usb_common marvell10g phy_generic spi_orion mdio_i2c i2c_core mvmdio phylink sbsa_gwdt ip_tables x_tables autofs4 [last unloaded: mvpp2]
        [ 2744.115654] CPU: 3 PID: 8357 Comm: kworker/3:2 Not tainted 5.3.0-rc2 #1
        [ 2744.115655] Hardware name: Marvell 8040 MACCHIATOBin Double-shot (DT)
        [ 2744.115665] Workqueue: events_power_efficient phylink_resolve [phylink]
        [ 2744.115669] pstate: a0000085 (NzCv daIf -PAN -UAO)
        [ 2744.115675] pc : __queue_work+0x9c/0x4d8
        [ 2744.115677] lr : __queue_work+0x170/0x4d8
        [ 2744.115678] sp : ffffff801001bd50
        [ 2744.115680] x29: ffffff801001bd50 x28: ffffffc422597600
        [ 2744.115684] x27: ffffff80109ae6f0 x26: ffffff80108e4018
        [ 2744.115688] x25: 0000000000000003 x24: 0000000000000004
        [ 2744.115691] x23: ffffff80109ae6e0 x22: 0000000000000017
        [ 2744.115694] x21: ffffffc42c030000 x20: ffffffc42209e8f8
        [ 2744.115697] x19: 0000000000000000 x18: 0000000000000000
        [ 2744.115699] x17: 0000000000000000 x16: 0000000000000000
        [ 2744.115701] x15: 0000000000000010 x14: ffffffffffffffff
        [ 2744.115702] x13: ffffff8090e2b95f x12: ffffff8010e2b967
        [ 2744.115704] x11: ffffff8010906000 x10: 0000000000000040
        [ 2744.115706] x9 : ffffff80109223b8 x8 : ffffff80109223b0
        [ 2744.115707] x7 : ffffffc42bc00068 x6 : 0000000000000000
        [ 2744.115709] x5 : ffffffc42bc00000 x4 : 0000000000000000
        [ 2744.115710] x3 : 0000000000000000 x2 : 0000000000000000
        [ 2744.115712] x1 : 0000000000000008 x0 : ffffffc42c030000
        [ 2744.115714] Call trace:
        [ 2744.115716]  __queue_work+0x9c/0x4d8
        [ 2744.115718]  delayed_work_timer_fn+0x28/0x38
        [ 2744.115722]  call_timer_fn+0x3c/0x180
        [ 2744.115723]  expire_timers+0x60/0x168
        [ 2744.115724]  run_timer_softirq+0xbc/0x1e8
        [ 2744.115727]  __do_softirq+0x128/0x320
        [ 2744.115731]  irq_exit+0xa4/0xc0
        [ 2744.115734]  __handle_domain_irq+0x70/0xc0
        [ 2744.115735]  gic_handle_irq+0x58/0xa8
        [ 2744.115737]  el1_irq+0xb8/0x140
        [ 2744.115738]  console_unlock+0x3a0/0x568
        [ 2744.115740]  vprintk_emit+0x200/0x2a0
        [ 2744.115744]  dev_vprintk_emit+0x1c8/0x1e4
        [ 2744.115747]  dev_printk_emit+0x6c/0x7c
        [ 2744.115751]  __netdev_printk+0x104/0x1d8
        [ 2744.115752]  netdev_printk+0x60/0x70
        [ 2744.115756]  phylink_resolve+0x38c/0x3c8 [phylink]
        [ 2744.115758]  process_one_work+0x1f8/0x448
        [ 2744.115760]  worker_thread+0x54/0x500
        [ 2744.115762]  kthread+0x12c/0x130
        [ 2744.115764]  ret_from_fork+0x10/0x1c
        [ 2744.115768] Code: aa1403e0 97fffbbe aa0003f5 b4000700 (f9400261)
    
    Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Matteo Croce <mcroce@redhat.com>
    Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c46905fb182334eaa6737e8faa9f6067a45c027
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Wed Jul 31 09:33:14 2019 +0300

    mlxsw: spectrum: Fix error path in mlxsw_sp_module_init()
    
    [ Upstream commit 28fe79000e9b0a6f99959869947f1ca305f14599 ]
    
    In case of sp2 pci driver registration fail, fix the error path to
    start with sp1 pci driver unregister.
    
    Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f186fb5ccf699487a38b5b924fa6068274ae7d4f
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Thu Jul 25 11:07:56 2019 +0800

    ipip: validate header length in ipip_tunnel_xmit
    
    [ Upstream commit 47d858d0bdcd47cc1c6c9eeca91b091dd9e55637 ]
    
    We need the same checks introduced by commit cb9f1b783850
    ("ip: validate header length on virtual device xmit") for
    ipip tunnel.
    
    Fixes: cb9f1b783850b ("ip: validate header length on virtual device xmit")
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bb2dd37cb878da69b43957804f2925d6ce33d1b
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Fri Jul 26 00:40:17 2019 +0800

    ip6_tunnel: fix possible use-after-free on xmit
    
    [ Upstream commit 01f5bffad555f8e22a61f4b1261fe09cf1b96994 ]
    
    ip4ip6/ip6ip6 tunnels run iptunnel_handle_offloads on xmit which
    can cause a possible use-after-free accessing iph/ipv6h pointer
    since the packet will be 'uncloned' running pskb_expand_head if
    it is a cloned gso skb.
    
    Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets")
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdcefa46c5c22fdff4960c6bdabf245af667ceaf
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Wed Jul 24 20:00:42 2019 +0800

    ip6_gre: reload ipv6h in prepare_ip6gre_xmit_ipv6
    
    [ Upstream commit 3bc817d665ac6d9de89f59df522ad86f5b5dfc03 ]
    
    Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull()
    which may change skb->data, so we need to re-load ipv6h at
    the right place.
    
    Fixes: 898b29798e36 ("ip6_gre: Refactor ip6gre xmit codes")
    Cc: William Tu <u9012063@gmail.com>
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Acked-by: William Tu <u9012063@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4c8899376c2eb363c70b0b200434cc9abd3d34e
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Jul 22 21:43:00 2019 -0700

    ife: error out when nla attributes are empty
    
    [ Upstream commit c8ec4632c6ac9cda0e8c3d51aa41eeab66585bd5 ]
    
    act_ife at least requires TCA_IFE_PARMS, so we have to bail out
    when there is no attribute passed in.
    
    Reported-by: syzbot+fbb5b288c9cb6a2eeac4@syzkaller.appspotmail.com
    Fixes: ef6980b6becb ("introduce IFE action")
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 774358df88f7259dafebb5876de4196826ca75a7
Author: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Date:   Tue Jul 23 19:32:41 2019 -0700

    bnx2x: Disable multi-cos feature.
    
    [ Upstream commit d1f0b5dce8fda09a7f5f04c1878f181d548e42f5 ]
    
    Commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") which enabled multi-cos
    feature after prolonged time in driver added some regression causing
    numerous issues (sudden reboots, tx timeout etc.) reported by customers.
    We plan to backout this commit and submit proper fix once we have root
    cause of issues reported with this feature enabled.
    
    Fixes: 3968d38917eb ("bnx2x: Fix Multi-Cos.")
    Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb4626784f398ae9222ed5e70ab79a2c74d9c74c
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Jul 30 22:21:41 2019 -0500

    atm: iphase: Fix Spectre v1 vulnerability
    
    [ Upstream commit ea443e5e98b5b74e317ef3d26bcaea54931ccdee ]
    
    board is controlled by user-space, hence leading to a potential
    exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] (local cap)
    drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half.  'iadev'
    drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half.  'iadev'
    drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half.  'iadev'
    drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half.  'iadev'
    drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' [r] (local cap)
    drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half.  'iadev'
    drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half.  'iadev'
    
    Fix this by sanitizing board before using it to index ia_dev and _ia_dev
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8440cdc77577e5177153e121229cff73c0ba4e6c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 7 18:44:12 2019 +0200

    IB: directly cast the sockaddr union to aockaddr
    
    Like commit 641114d2af31 ("RDMA: Directly cast the sockaddr union to
    sockaddr") we need to quiet gcc 9 from warning about this crazy union.
    That commit did not fix all of the warnings in 4.19 and older kernels
    because the logic in roce_resolve_route_from_path() was rewritten
    between 4.19 and 5.2 when that change happened.
    
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 608cfdfa9eb712a54900859dabae5c5c19a2a93c
Author: Sebastian Parschauer <s.parschauer@gmx.de>
Date:   Wed Jul 24 20:40:03 2019 +0200

    HID: Add quirk for HP X1200 PIXART OEM mouse
    
    commit 49869d2ea9eecc105a10724c1abf035151a3c4e2 upstream.
    
    The PixArt OEM mice are known for disconnecting every minute in
    runlevel 1 or 3 if they are not always polled. So add quirk
    ALWAYS_POLL for this one as well.
    
    Jonathan Teh (@jonathan-teh) reported and tested the quirk.
    Reference: https://github.com/sriemer/fix-linux-mouse/issues/15
    
    Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
    CC: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e830c2c3c1748613cdcd0df85e6edcd8b59d9336
Author: Aaron Armstrong Skomra <skomra@gmail.com>
Date:   Tue Jul 23 11:09:15 2019 -0700

    HID: wacom: fix bit shift for Cintiq Companion 2
    
    commit 693c3dab4e50403f91bca4b52fc6d8562a3180f6 upstream.
    
    The bit indicating BTN_6 on this device is overshifted
    by 2 bits, resulting in the incorrect button being
    reported.
    
    Also fix copy-paste mistake in comments.
    
    Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
    Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
    Link: https://github.com/linuxwacom/xf86-input-wacom/issues/71
    Fixes: c7f0522a1ad1 ("HID: wacom: Slim down wacom_intuos_pad processing")
    Cc: <stable@vger.kernel.org> # v4.5+
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2364ed0d8ed11e30757563312587516911c88ae3
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Aug 5 18:32:13 2019 -0700

    libnvdimm/bus: Fix wait_nvdimm_bus_probe_idle() ABBA deadlock
    
    commit ca6bf264f6d856f959c4239cda1047b587745c67 upstream.
    
    A multithreaded namespace creation/destruction stress test currently
    deadlocks with the following lockup signature:
    
        INFO: task ndctl:2924 blocked for more than 122 seconds.
              Tainted: G           OE     5.2.0-rc4+ #3382
        "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
        ndctl           D    0  2924   1176 0x00000000
        Call Trace:
         ? __schedule+0x27e/0x780
         schedule+0x30/0xb0
         wait_nvdimm_bus_probe_idle+0x8a/0xd0 [libnvdimm]
         ? finish_wait+0x80/0x80
         uuid_store+0xe6/0x2e0 [libnvdimm]
         kernfs_fop_write+0xf0/0x1a0
         vfs_write+0xb7/0x1b0
         ksys_write+0x5c/0xd0
         do_syscall_64+0x60/0x240
    
         INFO: task ndctl:2923 blocked for more than 122 seconds.
               Tainted: G           OE     5.2.0-rc4+ #3382
         "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
         ndctl           D    0  2923   1175 0x00000000
         Call Trace:
          ? __schedule+0x27e/0x780
          ? __mutex_lock+0x489/0x910
          schedule+0x30/0xb0
          schedule_preempt_disabled+0x11/0x20
          __mutex_lock+0x48e/0x910
          ? nvdimm_namespace_common_probe+0x95/0x4d0 [libnvdimm]
          ? __lock_acquire+0x23f/0x1710
          ? nvdimm_namespace_common_probe+0x95/0x4d0 [libnvdimm]
          nvdimm_namespace_common_probe+0x95/0x4d0 [libnvdimm]
          __dax_pmem_probe+0x5e/0x210 [dax_pmem_core]
          ? nvdimm_bus_probe+0x1d0/0x2c0 [libnvdimm]
          dax_pmem_probe+0xc/0x20 [dax_pmem]
          nvdimm_bus_probe+0x90/0x2c0 [libnvdimm]
          really_probe+0xef/0x390
          driver_probe_device+0xb4/0x100
    
    In this sequence an 'nd_dax' device is being probed and trying to take
    the lock on its backing namespace to validate that the 'nd_dax' device
    indeed has exclusive access to the backing namespace. Meanwhile, another
    thread is trying to update the uuid property of that same backing
    namespace. So one thread is in the probe path trying to acquire the
    lock, and the other thread has acquired the lock and tries to flush the
    probe path.
    
    Fix this deadlock by not holding the namespace device_lock over the
    wait_nvdimm_bus_probe_idle() synchronization step. In turn this requires
    the device_lock to be held on entry to wait_nvdimm_bus_probe_idle() and
    subsequently dropped internally to wait_nvdimm_bus_probe_idle().
    
    Cc: <stable@vger.kernel.org>
    Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace instantiation")
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Tested-by: Jane Chu <jane.chu@oracle.com>
    Link: https://lore.kernel.org/r/156341210094.292348.2384694131126767789.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f000e7b44901519b41bbe6352a9fb0afc5b6d18
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Aug 5 18:32:07 2019 -0700

    libnvdimm/bus: Prepare the nd_ioctl() path to be re-entrant
    
    commit 6de5d06e657acdbcf9637dac37916a4a5309e0f4 upstream.
    
    In preparation for not holding a lock over the execution of nd_ioctl(),
    update the implementation to allow multiple threads to be attempting
    ioctls at the same time. The bus lock still prevents multiple in-flight
    ->ndctl() invocations from corrupting each other's state, but static
    global staging buffers are moved to the heap.
    
    Reported-by: Vishal Verma <vishal.l.verma@intel.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Tested-by: Vishal Verma <vishal.l.verma@intel.com>
    Link: https://lore.kernel.org/r/156341208947.292348.10560140326807607481.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3248536919c17855ef5f2bc736d9565d9580706a
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Aug 5 18:32:02 2019 -0700

    libnvdimm/region: Register badblocks before namespaces
    
    commit 700cd033a82d466ad8f9615f9985525e45f8960a upstream.
    
    Namespace activation expects to be able to reference region badblocks.
    The following warning sometimes triggers when asynchronous namespace
    activation races in front of the completion of namespace probing. Move
    all possible namespace probing after region badblocks initialization.
    
    Otherwise, lockdep sometimes catches the uninitialized state of the
    badblocks seqlock with stack trace signatures like:
    
        INFO: trying to register non-static key.
        pmem2: detected capacity change from 0 to 136365211648
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
        CPU: 9 PID: 358 Comm: kworker/u80:5 Tainted: G           OE     5.2.0-rc4+ #3382
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
        Workqueue: events_unbound async_run_entry_fn
        Call Trace:
         dump_stack+0x85/0xc0
        pmem1.12: detected capacity change from 0 to 8589934592
         register_lock_class+0x56a/0x570
         ? check_object+0x140/0x270
         __lock_acquire+0x80/0x1710
         ? __mutex_lock+0x39d/0x910
         lock_acquire+0x9e/0x180
         ? nd_pfn_validate+0x28f/0x440 [libnvdimm]
         badblocks_check+0x93/0x1f0
         ? nd_pfn_validate+0x28f/0x440 [libnvdimm]
         nd_pfn_validate+0x28f/0x440 [libnvdimm]
         ? lockdep_hardirqs_on+0xf0/0x180
         nd_dax_probe+0x9a/0x120 [libnvdimm]
         nd_pmem_probe+0x6d/0x180 [nd_pmem]
         nvdimm_bus_probe+0x90/0x2c0 [libnvdimm]
    
    Fixes: 48af2f7e52f4 ("libnvdimm, pfn: during init, clear errors...")
    Cc: <stable@vger.kernel.org>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Link: https://lore.kernel.org/r/156341208365.292348.1547528796026249120.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d16bbdbbcb5002c5366cbf6402561d0350afd5fe
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Aug 5 18:31:56 2019 -0700

    libnvdimm/bus: Prevent duplicate device_unregister() calls
    
    commit 8aac0e2338916e273ccbd438a2b7a1e8c61749f5 upstream.
    
    A multithreaded namespace creation/destruction stress test currently
    fails with signatures like the following:
    
        sysfs group 'power' not found for kobject 'dax1.1'
        RIP: 0010:sysfs_remove_group+0x76/0x80
        Call Trace:
         device_del+0x73/0x370
         device_unregister+0x16/0x50
         nd_async_device_unregister+0x1e/0x30 [libnvdimm]
         async_run_entry_fn+0x39/0x160
         process_one_work+0x23c/0x5e0
         worker_thread+0x3c/0x390
    
        BUG: kernel NULL pointer dereference, address: 0000000000000020
        RIP: 0010:klist_put+0x1b/0x6c
        Call Trace:
         klist_del+0xe/0x10
         device_del+0x8a/0x2c9
         ? __switch_to_asm+0x34/0x70
         ? __switch_to_asm+0x40/0x70
         device_unregister+0x44/0x4f
         nd_async_device_unregister+0x22/0x2d [libnvdimm]
         async_run_entry_fn+0x47/0x15a
         process_one_work+0x1a2/0x2eb
         worker_thread+0x1b8/0x26e
    
    Use the kill_device() helper to atomically resolve the race of multiple
    threads issuing kill, device_unregister(), requests.
    
    Reported-by: Jane Chu <jane.chu@oracle.com>
    Reported-by: Erwin Tsaur <erwin.tsaur@oracle.com>
    Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver...")
    Cc: <stable@vger.kernel.org>
    Link: https://github.com/pmem/ndctl/issues/96
    Tested-by: Tested-by: Jane Chu <jane.chu@oracle.com>
    Link: https://lore.kernel.org/r/156341207846.292348.10435719262819764054.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c23106d4276d7d03f1b3e9dfca40fcf793a6ebab
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Aug 5 18:31:51 2019 -0700

    drivers/base: Introduce kill_device()
    
    commit 00289cd87676e14913d2d8492d1ce05c4baafdae upstream.
    
    The libnvdimm subsystem arranges for devices to be destroyed as a result
    of a sysfs operation. Since device_unregister() cannot be called from
    an actively running sysfs attribute of the same device libnvdimm
    arranges for device_unregister() to be performed in an out-of-line async
    context.
    
    The driver core maintains a 'dead' state for coordinating its own racing
    async registration / de-registration requests. Rather than add local
    'dead' state tracking infrastructure to libnvdimm device objects, export
    the existing state tracking via a new kill_device() helper.
    
    The kill_device() helper simply marks the device as dead, i.e. that it
    is on its way to device_del(), or returns that the device was already
    dead. This can be used in advance of calling device_unregister() for
    subsystems like libnvdimm that might need to handle multiple user
    threads racing to delete a device.
    
    This refactoring does not change any behavior, but it is a pre-requisite
    for follow-on fixes and therefore marked for -stable.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver...")
    Cc: <stable@vger.kernel.org>
    Tested-by: Jane Chu <jane.chu@oracle.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/156341207332.292348.14959761496009347574.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c43f84efd6d01fc646feb67d2b2b500435b191a
Author: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Date:   Mon Aug 5 18:31:45 2019 -0700

    driver core: Establish order of operations for device_add and device_del via bitflag
    
    commit 3451a495ef244a88ed6317a035299d835554d579 upstream.
    
    Add an additional bit flag to the device_private struct named "dead".
    
    This additional flag provides a guarantee that when a device_del is
    executed on a given interface an async worker will not attempt to attach
    the driver following the earlier device_del call. Previously this
    guarantee was not present and could result in the device_del call
    attempting to remove a driver from an interface only to have the async
    worker attempt to probe the driver later when it finally completes the
    asynchronous probe call.
    
    One additional change added was that I pulled the check for dev->driver
    out of the __device_attach_driver call and instead placed it in the
    __device_attach_async_helper call. This was motivated by the fact that the
    only other caller of this, __device_attach, had already taken the
    device_lock() and checked for dev->driver. Instead of testing for this
    twice in this path it makes more sense to just consolidate the dev->dead
    and dev->driver checks together into one set of checks.
    
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a152a7b411a54b73707f37ab753cd907c3edfc56
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed May 1 11:07:40 2019 -0700

    gcc-9: don't warn about uninitialized variable
    
    commit cf676908846a06443fa5e6724ca3f5dd7460eca1 upstream.
    
    I'm not sure what made gcc warn about this code now.  The 'ret' variable
    does end up initialized in all cases, but it's definitely not obvious,
    so the compiler is quite reasonable to warn about this.
    
    So just add initialization to make it all much more obvious both to
    compilers and to humans.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93d6f0841eef6304c13803a84588f00476b06a14
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Jul 24 11:00:55 2019 +0200

    scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure
    
    commit 023358b136d490ca91735ac6490db3741af5a8bd upstream.
    
    Gcc-9 complains for a memset across pointer boundaries, which happens as
    the code tries to allocate a flexible array on the stack.  Turns out we
    cannot do this without relying on gcc-isms, so with this patch we'll embed
    the fc_rport_priv structure into fcoe_rport, can use the normal
    'container_of' outcast, and will only have to do a memset over one
    structure.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>