commit 19d1c763e849fb78ddf2afe0e2625d79ed4c8a11
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Dec 21 13:27:07 2020 +0100

    Linux 5.4.85
    
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20201219125341.384025953@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 484ac6279ad2fc74ef64a10fdc97c82eb43c32b8
Author: Xiaochen Shen <xiaochen.shen@intel.com>
Date:   Fri Dec 4 14:27:59 2020 +0800

    x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabled
    
    commit 06c5fe9b12dde1b62821f302f177c972bb1c81f9 upstream
    
    The MBA software controller (mba_sc) is a feedback loop which
    periodically reads MBM counters and tries to restrict the bandwidth
    below a user-specified value. It tags along the MBM counter overflow
    handler to do the updates with 1s interval in mbm_update() and
    update_mba_bw().
    
    The purpose of mbm_update() is to periodically read the MBM counters to
    make sure that the hardware counter doesn't wrap around more than once
    between user samplings. mbm_update() calls __mon_event_count() for local
    bandwidth updating when mba_sc is not enabled, but calls mbm_bw_count()
    instead when mba_sc is enabled. __mon_event_count() will not be called
    for local bandwidth updating in MBM counter overflow handler, but it is
    still called when reading MBM local bandwidth counter file
    'mbm_local_bytes', the call path is as below:
    
      rdtgroup_mondata_show()
        mon_event_read()
          mon_event_count()
            __mon_event_count()
    
    In __mon_event_count(), m->chunks is updated by delta chunks which is
    calculated from previous MSR value (m->prev_msr) and current MSR value.
    When mba_sc is enabled, m->chunks is also updated in mbm_update() by
    mistake by the delta chunks which is calculated from m->prev_bw_msr
    instead of m->prev_msr. But m->chunks is not used in update_mba_bw() in
    the mba_sc feedback loop.
    
    When reading MBM local bandwidth counter file, m->chunks was changed
    unexpectedly by mbm_bw_count(). As a result, the incorrect local
    bandwidth counter which calculated from incorrect m->chunks is shown to
    the user.
    
    Fix this by removing incorrect m->chunks updating in mbm_bw_count() in
    MBM counter overflow handler, and always calling __mon_event_count() in
    mbm_update() to make sure that the hardware local bandwidth counter
    doesn't wrap around.
    
    Test steps:
      # Run workload with aggressive memory bandwidth (e.g., 10 GB/s)
      git clone https://github.com/intel/intel-cmt-cat && cd intel-cmt-cat
      && make
      ./tools/membw/membw -c 0 -b 10000 --read
    
      # Enable MBA software controller
      mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl
    
      # Create control group c1
      mkdir /sys/fs/resctrl/c1
    
      # Set MB throttle to 6 GB/s
      echo "MB:0=6000;1=6000" > /sys/fs/resctrl/c1/schemata
    
      # Write PID of the workload to tasks file
      echo `pidof membw` > /sys/fs/resctrl/c1/tasks
    
      # Read local bytes counters twice with 1s interval, the calculated
      # local bandwidth is not as expected (approaching to 6 GB/s):
      local_1=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
      sleep 1
      local_2=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
      echo "local b/w (bytes/s):" `expr $local_2 - $local_1`
    
    Before fix:
      local b/w (bytes/s): 11076796416
    
    After fix:
      local b/w (bytes/s): 5465014272
    
    Fixes: ba0f26d8529c (x86/intel_rdt/mba_sc: Prepare for feedback loop)
    Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/1607063279-19437-1-git-send-email-xiaochen.shen@intel.com
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb3f42cf5e67c6667831521c8d914b353b571fed
Author: James Morse <james.morse@arm.com>
Date:   Wed Jul 8 16:39:20 2020 +0000

    x86/resctrl: Remove unused struct mbm_state::chunks_bw
    
    commit abe8f12b44250d02937665033a8b750c1bfeb26e upstream
    
    Nothing reads struct mbm_states's chunks_bw value, its a copy of
    chunks. Remove it.
    
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Link: https://lkml.kernel.org/r/20200708163929.2783-2-james.morse@arm.com
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4f90940701589acb67498fbf1626218dd6220b5
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Dec 3 21:07:05 2020 -0800

    membarrier: Explicitly sync remote cores when SYNC_CORE is requested
    
    commit 758c9373d84168dc7d039cf85a0e920046b17b41 upstream.
    
    membarrier() does not explicitly sync_core() remote CPUs; instead, it
    relies on the assumption that an IPI will result in a core sync.  On x86,
    this may be true in practice, but it's not architecturally reliable.  In
    particular, the SDM and APM do not appear to guarantee that interrupt
    delivery is serializing.  While IRET does serialize, IPI return can
    schedule, thereby switching to another task in the same mm that was
    sleeping in a syscall.  The new task could then SYSRET back to usermode
    without ever executing IRET.
    
    Make this more robust by explicitly calling sync_core_before_usermode()
    on remote cores.  (This also helps people who search the kernel tree for
    instances of sync_core() and sync_core_before_usermode() -- one might be
    surprised that the core membarrier code doesn't currently show up in a
    such a search.)
    
    Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE")
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/776b448d5f7bd6b12690707f5ed67bcda7f1d427.1607058304.git.luto@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a840e37ef8003d70c3aa5ce2ee1a3e5ce4647431
Author: Kamal Mostafa <kamal@canonical.com>
Date:   Wed Dec 16 10:13:53 2020 -0800

    Revert "selftests/ftrace: check for do_sys_openat2 in user-memory test"
    
    This reverts commit 9110e2f2633dc9383a3a4711a0067094f6948783.
    
    This commit is not suitable for 5.4-stable because the openat2 system
    call does not exist in v5.4.
    
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa17a20d640d5a1f5c8e78d2a1c7efb6020660b7
Author: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Date:   Sat Dec 5 01:48:08 2020 +0100

    KVM: mmu: Fix SPTE encoding of MMIO generation upper half
    
    commit 34c0f6f2695a2db81e09a3ab7bdb2853f45d4d3d upstream.
    
    Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
    cleaned up the computation of MMIO generation SPTE masks, however it
    introduced a bug how the upper part was encoded:
    SPTE bits 52-61 were supposed to contain bits 10-19 of the current
    generation number, however a missing shift encoded bits 1-10 there instead
    (mostly duplicating the lower part of the encoded generation number that
    then consisted of bits 1-9).
    
    In the meantime, the upper part was shrunk by one bit and moved by
    subsequent commits to become an upper half of the encoded generation number
    (bits 9-17 of bits 0-17 encoded in a SPTE).
    
    In addition to the above, commit 56871d444bc4 ("KVM: x86: fix overlap between SPTE_MMIO_MASK and generation")
    has changed the SPTE bit range assigned to encode the generation number and
    the total number of bits encoded but did not update them in the comment
    attached to their defines, nor in the KVM MMU doc.
    Let's do it here, too, since it is too trivial thing to warrant a separate
    commit.
    
    Fixes: cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Message-Id: <156700708db2a5296c5ed7a8b9ac71f1e9765c85.1607129096.git.maciej.szmigiero@oracle.com>
    Cc: stable@vger.kernel.org
    [Reorganize macros so that everything is computed from the bit ranges. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb07f4c93e62a310afd9aa6250744818d7f3de7d
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Thu Dec 10 06:52:57 2020 +0100

    serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
    
    commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream.
    
    It has been observed that once per 300-1300 port openings the first
    transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
    as "e" on the wire). It only happened if single byte has been transmitted
    right after port open, which means, DMA is not used for this transfer and
    the corruption never happened afterwards.
    
    Therefore I've carefully re-read the MDR1 errata (link below), which says
    "when accessing the MDR1 registers that causes a dummy under-run condition
    that will freeze the UART in IrDA transmission. In UART mode, this may
    corrupt the transferred data". Strictly speaking,
    omap_8250_mdr1_errataset() performs a read access and if the value is the
    same as should be written, exits without errata-recommended FIFO reset.
    
    A brief check of the serial_omap_mdr1_errataset() from the competing
    omap-serial driver showed it has no read access of MDR1. After removing the
    read access from omap_8250_mdr1_errataset() the data corruption never
    happened any more.
    
    Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
    Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14482dc42c282dabadd3540e0b3b7766eddffee9
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 9 09:45:52 2020 +0100

    ALSA: pcm: oss: Fix potential out-of-bounds shift
    
    commit 175b8d89fe292796811fdee87fa39799a5b6b87a upstream.
    
    syzbot spotted a potential out-of-bounds shift in the PCM OSS layer
    where it calculates the buffer size with the arbitrary shift value
    given via an ioctl.
    
    Add a range check for avoiding the undefined behavior.
    As the value can be treated by a signed integer, the max shift should
    be 30.
    
    Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209084552.17109-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c94a31c19225530482eed6ea6077028908549aa3
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Oct 19 12:06:30 2020 +0200

    USB: sisusbvga: Make console support depend on BROKEN
    
    commit 862ee699fefe1e6d6f2c1518395f0b999b8beb15 upstream.
    
    The console part of sisusbvga is broken vs. printk(). It uses in_atomic()
    to detect contexts in which it cannot sleep despite the big fat comment in
    preempt.h which says: Do not use in_atomic() in driver code.
    
    in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which
    means that spin/rw_lock held regions are not detected by it.
    
    There is no way to make this work by handing context information through to
    the driver and this only can be solved once the core printk infrastructure
    supports sleepable console drivers.
    
    Make it depend on BROKEN for now.
    
    Fixes: 1bbb4f2035d9 ("[PATCH] USB: sisusb[vga] update")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Thomas Winischhofer <thomas@winischhofer.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: linux-usb@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20201019101109.603244207@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ad8fc6cce018467c50ae18a70636c062d0d6e81
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Dec 9 16:26:39 2020 +0100

    USB: UAS: introduce a quirk to set no_write_same
    
    commit 8010622c86ca5bb44bc98492f5968726fc7c7a21 upstream.
    
    UAS does not share the pessimistic assumption storage is making that
    devices cannot deal with WRITE_SAME.  A few devices supported by UAS,
    are reported to not deal well with WRITE_SAME. Those need a quirk.
    
    Add it to the device that needs it.
    
    Reported-by: David C. Partridge <david.partridge@perdrix.co.uk>
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209152639.9195-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 397d0ae4cb90bcec508f341adb64e1bdb5ce3122
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Dec 8 11:29:10 2020 +0200

    xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LP
    
    commit c4d1ca05b8e68a4b5a3c4455cb6ec25b3df6d9dd upstream.
    
    The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt
    controller awake if the host controller is not allowed to sleep.
    This is the case even if no USB devices are connected to the host.
    
    Add the Intel Alpine Ridge LP product-id to the list of product-ids
    for which we allow runtime PM by default.
    
    Fixes: 2815ef7fe4d4 ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20201208092912.1773650-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32c820e016b4b0a46c2015c0dce39310ebbeed3b
Author: Li Jun <jun.li@nxp.com>
Date:   Tue Dec 8 11:29:12 2020 +0200

    xhci: Give USB2 ports time to enter U3 in bus suspend
    
    commit c1373f10479b624fb6dba0805d673e860f1b421d upstream.
    
    If a USB2 device wakeup is not enabled/supported the link state may
    still be in U0 in xhci_bus_suspend(), where it's then manually put
    to suspended U3 state.
    
    Just as with selective suspend the device needs time to enter U3
    suspend before continuing with further suspend operations
    (e.g. system suspend), otherwise we may enter system suspend with link
    state in U0.
    
    [commit message rewording -Mathias]
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20201208092912.1773650-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5828ae0c19207463f183455159f836e815a8fa19
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 11 14:00:48 2020 +0100

    ALSA: usb-audio: Fix control 'access overflow' errors from chmap
    
    commit c6dde8ffd071aea9d1ce64279178e470977b235c upstream.
    
    The current channel-map control implementation in USB-audio driver may
    lead to an error message like
      "control 3:0:0:Playback Channel Map:0: access overflow"
    when CONFIG_SND_CTL_VALIDATION is set.  It's because the chmap get
    callback clears the whole array no matter which count is set, and
    rather the false-positive detection.
    
    This patch fixes the problem by clearing only the needed array range
    at usb_chmap_ctl_get().
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201211130048.6358-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e72a55ea71687483a0b1596f62a6db392d42bed3
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Dec 9 09:45:51 2020 +0100

    ALSA: usb-audio: Fix potential out-of-bounds shift
    
    commit 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba upstream.
    
    syzbot spotted a potential out-of-bounds shift in the USB-audio format
    parser that receives the arbitrary shift value from the USB
    descriptor.
    
    Add a range check for avoiding the undefined behavior.
    
    Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201209084552.17109-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56339afa39e54c75ce2893fee84631eff72d3fa5
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Dec 7 14:03:23 2020 +0100

    USB: add RESET_RESUME quirk for Snapscan 1212
    
    commit 08a02f954b0def3ada8ed6d4b2c7bcb67e885e9c upstream.
    
    I got reports that some models of this old scanner need
    this when using runtime PM.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201207130323.23857-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52c2ada6fe5e7932cd3b22a940145224a55cf7cf
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Fri Dec 4 06:24:49 2020 +0000

    USB: dummy-hcd: Fix uninitialized array use in init()
    
    commit e90cfa813da7a527785033a0b247594c2de93dd8 upstream.
    
    This error path
    
            err_add_pdata:
                    for (i = 0; i < mod_data.num; i++)
                            kfree(dum[i]);
    
    can be triggered when not all dum's elements are initialized.
    
    Fix this by initializing all dum's elements to NULL.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/1607063090-3426-1-git-send-email-minhquangbui99@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 497993377bca870f9bee1d8d2fa4a7f88a0135b6
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Nov 30 16:32:55 2020 -0500

    ktest.pl: If size of log is too big to email, email error message
    
    commit 8cd6bc0359deebd8500e6de95899a8a78d3ec4ba upstream.
    
    If the size of the error log is too big to send via email, and the sending
    fails, it wont email any result. This can be confusing for the user who is
    waiting for an email on the completion of the tests.
    
    If it fails to send email, then try again without the log file stating that
    it failed to send an email. Obviously this will not be of use if the sending
    of email failed for some other reasons, but it will at least give the user
    some information when it fails for the most common reason.
    
    Cc: stable@vger.kernel.org
    Fixes: c2d84ddb338c8 ("ktest.pl: Add MAIL_COMMAND option to define how to send email")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8d28a5415007c90c8f3c1fb43243525fb9bd833
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Mon Dec 7 18:51:40 2020 +0800

    net: stmmac: delete the eee_ctrl_timer after napi disabled
    
    [ Upstream commit 5f58591323bf3f342920179f24515935c4b5fd60 ]
    
    There have chance to re-enable the eee_ctrl_timer and fire the timer
    in napi callback after delete the timer in .stmmac_release(), which
    introduces to access eee registers in the timer function after clocks
    are disabled then causes system hang. Found this issue when do
    suspend/resume and reboot stress test.
    
    It is safe to delete the timer after napi disabled and disable lpi mode.
    
    Fixes: d765955d2ae0b ("stmmac: add the Energy Efficient Ethernet support")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee08543f459866f990a4a30f8ff76187172bd314
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Dec 5 22:32:07 2020 +0100

    net: stmmac: dwmac-meson8b: fix mask definition of the m250_sel mux
    
    [ Upstream commit 82ca4c922b8992013a238d65cf4e60cc33e12f36 ]
    
    The m250_sel mux clock uses bit 4 in the PRG_ETH0 register. Fix this by
    shifting the PRG_ETH0_CLK_M250_SEL_MASK accordingly as the "mask" in
    struct clk_mux expects the mask relative to the "shift" field in the
    same struct.
    
    While here, get rid of the PRG_ETH0_CLK_M250_SEL_SHIFT macro and use
    __ffs() to determine it from the existing PRG_ETH0_CLK_M250_SEL_MASK
    macro.
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20201205213207.519341-1-martin.blumenstingl@googlemail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ae78c6926cc3f9d2670589e2e96d27778d8252a
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Tue Dec 8 09:53:42 2020 +0800

    net: ll_temac: Fix potential NULL dereference in temac_probe()
    
    [ Upstream commit cc6596fc7295e9dcd78156ed42f9f8e1221f7530 ]
    
    platform_get_resource() may fail and in this case a NULL dereference
    will occur.
    
    Fix it to use devm_platform_ioremap_resource() instead of calling
    platform_get_resource() and devm_ioremap().
    
    This is detected by Coccinelle semantic patch.
    
    @@
    expression pdev, res, n, t, e, e1, e2;
    @@
    
    res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n);
    + if (!res)
    +   return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap(e1, res->start, e2);
    
    Fixes: 8425c41d1ef7 ("net: ll_temac: Extend support to non-device-tree platforms")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Esben Haabendal <esben@geanix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 717a140a3635bebeda29f7ef4ef00d0c4f98af83
Author: Moshe Shemesh <moshe@mellanox.com>
Date:   Wed Dec 9 15:03:39 2020 +0200

    net/mlx4_en: Handle TX error CQE
    
    [ Upstream commit ba603d9d7b1215c72513d7c7aa02b6775fd4891b ]
    
    In case error CQE was found while polling TX CQ, the QP is in error
    state and all posted WQEs will generate error CQEs without any data
    transmitted. Fix it by reopening the channels, via same method used for
    TX timeout handling.
    
    In addition add some more info on error CQE and WQE for debug.
    
    Fixes: bd2f631d7c60 ("net/mlx4_en: Notify user when TX ring in error state")
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0363dcabbd12f946353518567bef19ec58cbd19
Author: Sergej Bauer <sbauer@blackbox.su>
Date:   Mon Nov 2 01:35:55 2020 +0300

    lan743x: fix for potential NULL pointer dereference with bare card
    
    [ Upstream commit e9e13b6adc338be1eb88db87bcb392696144bd02 ]
    
    This is the 3rd revision of the patch fix for potential null pointer dereference
    with lan743x card.
    
    The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN"
    commant where ethN is the interface with lan743x card. Example:
    
    $ sudo ethtool eth7
    dmesg:
    [  103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340
    ...
    [  103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy]
    ...
    [  103.511629] Call Trace:
    [  103.511666]  lan743x_ethtool_get_wol+0x21/0x40 [lan743x]
    [  103.511724]  dev_ethtool+0x1507/0x29d0
    [  103.511769]  ? avc_has_extended_perms+0x17f/0x440
    [  103.511820]  ? tomoyo_init_request_info+0x84/0x90
    [  103.511870]  ? tomoyo_path_number_perm+0x68/0x1e0
    [  103.511919]  ? tty_insert_flip_string_fixed_flag+0x82/0xe0
    [  103.511973]  ? inet_ioctl+0x187/0x1d0
    [  103.512016]  dev_ioctl+0xb5/0x560
    [  103.512055]  sock_do_ioctl+0xa0/0x140
    [  103.512098]  sock_ioctl+0x2cb/0x3c0
    [  103.512139]  __x64_sys_ioctl+0x84/0xc0
    [  103.512183]  do_syscall_64+0x33/0x80
    [  103.512224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  103.512274] RIP: 0033:0x7f54a9cba427
    ...
    
    Previous versions can be found at:
    v1:
    initial version
        https://lkml.org/lkml/2020/10/28/921
    
    v2:
    do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip
    the call of phy_ethtool_set_wol() instead.
        https://lkml.org/lkml/2020/10/31/380
    
    v3:
    in function lan743x_ethtool_set_wol:
    use ternary operator instead of if-else sentence (review by Markus Elfring)
    return -ENETDOWN insted of -EIO (review by Andrew Lunn)
    
    Signed-off-by: Sergej Bauer <sbauer@blackbox.su>
    
    Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.su
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4107a0f88026a1703a31e1cd0402d144e109cfc
Author: Moshe Shemesh <moshe@mellanox.com>
Date:   Wed Dec 9 15:03:38 2020 +0200

    net/mlx4_en: Avoid scheduling restart task if it is already running
    
    [ Upstream commit fed91613c9dd455dd154b22fa8e11b8526466082 ]
    
    Add restarting state flag to avoid scheduling another restart task while
    such task is already running. Change task name from watchdog_task to
    restart_task to better fit the task role.
    
    Fixes: 1e338db56e5a ("mlx4_en: Fix a race at restart task")
    Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit add880d788f08fe400203b1f934819f9bb883a94
Author: Neal Cardwell <ncardwell@google.com>
Date:   Tue Dec 8 22:57:59 2020 -0500

    tcp: fix cwnd-limited bug for TSO deferral where we send nothing
    
    [ Upstream commit 299bcb55ecd1412f6df606e9dc0912d55610029e ]
    
    When cwnd is not a multiple of the TSO skb size of N*MSS, we can get
    into persistent scenarios where we have the following sequence:
    
    (1) ACK for full-sized skb of N*MSS arrives
      -> tcp_write_xmit() transmit full-sized skb with N*MSS
      -> move pacing release time forward
      -> exit tcp_write_xmit() because pacing time is in the future
    
    (2) TSQ callback or TCP internal pacing timer fires
      -> try to transmit next skb, but TSO deferral finds remainder of
         available cwnd is not big enough to trigger an immediate send
         now, so we defer sending until the next ACK.
    
    (3) repeat...
    
    So we can get into a case where we never mark ourselves as
    cwnd-limited for many seconds at a time, even with
    bulk/infinite-backlog senders, because:
    
    o In case (1) above, every time in tcp_write_xmit() we have enough
    cwnd to send a full-sized skb, we are not fully using the cwnd
    (because cwnd is not a multiple of the TSO skb size). So every time we
    send data, we are not cwnd limited, and so in the cwnd-limited
    tracking code in tcp_cwnd_validate() we mark ourselves as not
    cwnd-limited.
    
    o In case (2) above, every time in tcp_write_xmit() that we try to
    transmit the "remainder" of the cwnd but defer, we set the local
    variable is_cwnd_limited to true, but we do not send any packets, so
    sent_pkts is zero, so we don't call the cwnd-limited logic to update
    tp->is_cwnd_limited.
    
    Fixes: ca8a22634381 ("tcp: make cwnd-limited checks measurement-based, and gentler")
    Reported-by: Ingemar Johansson <ingemar.s.johansson@ericsson.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20201209035759.1225145-1-ncardwell.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5189c070a0d7f4682a80149fcaa403b788ce625a
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 8 08:21:31 2020 -0800

    tcp: select sane initial rcvq_space.space for big MSS
    
    [ Upstream commit 72d05c00d7ecda85df29abd046da7e41cc071c17 ]
    
    Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
    small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate various MSS.
    
    This is no longer the case, and Hazem Mohamed Abuelfotoh reported
    that DRS would not work for MTU 9000 endpoints receiving regular (1500 bytes) frames.
    
    Root cause is that tcp_init_buffer_space() uses tp->rcv_wnd for upper limit
    of rcvq_space.space computation, while it can select later a smaller
    value for tp->rcv_ssthresh and tp->window_clamp.
    
    ss -temoi on receiver would show :
    
    skmem:(r0,rb131072,t0,tb46080,f0,w0,o0,bl0,d0) rcv_space:62496 rcv_ssthresh:56596
    
    This means that TCP can not increase its window in tcp_grow_window(),
    and that DRS can never kick.
    
    Fix this by making sure that rcvq_space.space is not bigger than number of bytes
    that can be held in TCP receive queue.
    
    People unable/unwilling to change their kernel can work around this issue by
    selecting a bigger tcp_rmem[1] value as in :
    
    echo "4096 196608 6291456" >/proc/sys/net/ipv4/tcp_rmem
    
    Based on an initial report and patch from Hazem Mohamed Abuelfotoh
     https://lore.kernel.org/netdev/20201204180622.14285-1-abuehaze@amazon.com/
    
    Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
    Fixes: 041a14d26715 ("tcp: start receiver buffer autotuning sooner")
    Reported-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 318d90218b216c45f001b6b23f8ff8da719ae885
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Mon Dec 7 18:51:39 2020 +0800

    net: stmmac: free tx skb buffer in stmmac_resume()
    
    [ Upstream commit 4ec236c7c51f89abb0224a4da4a6b77f9beb6600 ]
    
    When do suspend/resume test, there have WARN_ON() log dump from
    stmmac_xmit() funciton, the code logic:
            entry = tx_q->cur_tx;
            first_entry = entry;
            WARN_ON(tx_q->tx_skbuff[first_entry]);
    
    In normal case, tx_q->tx_skbuff[txq->cur_tx] should be NULL because
    the skb should be handled and freed in stmmac_tx_clean().
    
    But stmmac_resume() reset queue parameters like below, skb buffers
    may not be freed.
            tx_q->cur_tx = 0;
            tx_q->dirty_tx = 0;
    
    So free tx skb buffer in stmmac_resume() to avoid warning and
    memory leak.
    
    log:
    [   46.139824] ------------[ cut here ]------------
    [   46.144453] WARNING: CPU: 0 PID: 0 at drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3235 stmmac_xmit+0x7a0/0x9d0
    [   46.154969] Modules linked in: crct10dif_ce vvcam(O) flexcan can_dev
    [   46.161328] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      5.4.24-2.1.0+g2ad925d15481 #1
    [   46.170369] Hardware name: NXP i.MX8MPlus EVK board (DT)
    [   46.175677] pstate: 80000005 (Nzcv daif -PAN -UAO)
    [   46.180465] pc : stmmac_xmit+0x7a0/0x9d0
    [   46.184387] lr : dev_hard_start_xmit+0x94/0x158
    [   46.188913] sp : ffff800010003cc0
    [   46.192224] x29: ffff800010003cc0 x28: ffff000177e2a100
    [   46.197533] x27: ffff000176ef0840 x26: ffff000176ef0090
    [   46.202842] x25: 0000000000000000 x24: 0000000000000000
    [   46.208151] x23: 0000000000000003 x22: ffff8000119ddd30
    [   46.213460] x21: ffff00017636f000 x20: ffff000176ef0cc0
    [   46.218769] x19: 0000000000000003 x18: 0000000000000000
    [   46.224078] x17: 0000000000000000 x16: 0000000000000000
    [   46.229386] x15: 0000000000000079 x14: 0000000000000000
    [   46.234695] x13: 0000000000000003 x12: 0000000000000003
    [   46.240003] x11: 0000000000000010 x10: 0000000000000010
    [   46.245312] x9 : ffff00017002b140 x8 : 0000000000000000
    [   46.250621] x7 : ffff00017636f000 x6 : 0000000000000010
    [   46.255930] x5 : 0000000000000001 x4 : ffff000176ef0000
    [   46.261238] x3 : 0000000000000003 x2 : 00000000ffffffff
    [   46.266547] x1 : ffff000177e2a000 x0 : 0000000000000000
    [   46.271856] Call trace:
    [   46.274302]  stmmac_xmit+0x7a0/0x9d0
    [   46.277874]  dev_hard_start_xmit+0x94/0x158
    [   46.282056]  sch_direct_xmit+0x11c/0x338
    [   46.285976]  __qdisc_run+0x118/0x5f0
    [   46.289549]  net_tx_action+0x110/0x198
    [   46.293297]  __do_softirq+0x120/0x23c
    [   46.296958]  irq_exit+0xb8/0xd8
    [   46.300098]  __handle_domain_irq+0x64/0xb8
    [   46.304191]  gic_handle_irq+0x5c/0x148
    [   46.307936]  el1_irq+0xb8/0x180
    [   46.311076]  cpuidle_enter_state+0x84/0x360
    [   46.315256]  cpuidle_enter+0x34/0x48
    [   46.318829]  call_cpuidle+0x18/0x38
    [   46.322314]  do_idle+0x1e0/0x280
    [   46.325539]  cpu_startup_entry+0x24/0x40
    [   46.329460]  rest_init+0xd4/0xe0
    [   46.332687]  arch_call_rest_init+0xc/0x14
    [   46.336695]  start_kernel+0x420/0x44c
    [   46.340353] ---[ end trace bc1ee695123cbacd ]---
    
    Fixes: 47dd7a540b8a0 ("net: add support for STMicroelectronics Ethernet controllers.")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8d39e13668a04f8deee9ec026ae6e9900c01cf1
Author: Joseph Huang <Joseph.Huang@garmin.com>
Date:   Fri Dec 4 18:56:28 2020 -0500

    bridge: Fix a deadlock when enabling multicast snooping
    
    [ Upstream commit 851d0a73c90e6c8c63fef106c6c1e73df7e05d9d ]
    
    When enabling multicast snooping, bridge module deadlocks on multicast_lock
    if 1) IPv6 is enabled, and 2) there is an existing querier on the same L2
    network.
    
    The deadlock was caused by the following sequence: While holding the lock,
    br_multicast_open calls br_multicast_join_snoopers, which eventually causes
    IP stack to (attempt to) send out a Listener Report (in igmp6_join_group).
    Since the destination Ethernet address is a multicast address, br_dev_xmit
    feeds the packet back to the bridge via br_multicast_rcv, which in turn
    calls br_multicast_add_group, which then deadlocks on multicast_lock.
    
    The fix is to move the call br_multicast_join_snoopers outside of the
    critical section. This works since br_multicast_join_snoopers only deals
    with IP and does not modify any multicast data structures of the bridge,
    so there's no need to hold the lock.
    
    Steps to reproduce:
    1. sysctl net.ipv6.conf.all.force_mld_version=1
    2. have another querier
    3. ip link set dev bridge type bridge mcast_snooping 0 && \
       ip link set dev bridge type bridge mcast_snooping 1 < deadlock >
    
    A typical call trace looks like the following:
    
    [  936.251495]  _raw_spin_lock+0x5c/0x68
    [  936.255221]  br_multicast_add_group+0x40/0x170 [bridge]
    [  936.260491]  br_multicast_rcv+0x7ac/0xe30 [bridge]
    [  936.265322]  br_dev_xmit+0x140/0x368 [bridge]
    [  936.269689]  dev_hard_start_xmit+0x94/0x158
    [  936.273876]  __dev_queue_xmit+0x5ac/0x7f8
    [  936.277890]  dev_queue_xmit+0x10/0x18
    [  936.281563]  neigh_resolve_output+0xec/0x198
    [  936.285845]  ip6_finish_output2+0x240/0x710
    [  936.290039]  __ip6_finish_output+0x130/0x170
    [  936.294318]  ip6_output+0x6c/0x1c8
    [  936.297731]  NF_HOOK.constprop.0+0xd8/0xe8
    [  936.301834]  igmp6_send+0x358/0x558
    [  936.305326]  igmp6_join_group.part.0+0x30/0xf0
    [  936.309774]  igmp6_group_added+0xfc/0x110
    [  936.313787]  __ipv6_dev_mc_inc+0x1a4/0x290
    [  936.317885]  ipv6_dev_mc_inc+0x10/0x18
    [  936.321677]  br_multicast_open+0xbc/0x110 [bridge]
    [  936.326506]  br_multicast_toggle+0xec/0x140 [bridge]
    
    Fixes: 4effd28c1245 ("bridge: join all-snoopers multicast address")
    Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
    Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Link: https://lore.kernel.org/r/20201204235628.50653-1-Joseph.Huang@garmin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb327f83cf5eeaf203b55f1589666a3062c7dd61
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Fri Dec 4 19:15:05 2020 +0200

    enetc: Fix reporting of h/w packet counters
    
    [ Upstream commit eb96b686fc2c601e78903cc61b6cf4588ddde013 ]
    
    Noticed some inconsistencies in packet statistics reporting.
    This patch adds the missing Tx packet counter registers to
    ethtool reporting and fixes the information strings for a
    few of them.
    
    Fixes: 16eb4c85c964 ("enetc: Add ethtool statistics")
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20201204171505.21389-1-claudiu.manoil@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 408c8213ee973273f9620167980a9c67f11e0271
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Dec 7 15:55:40 2020 +0800

    udp: fix the proto value passed to ip_protocol_deliver_rcu for the segments
    
    [ Upstream commit 10c678bd0a035ac2c64a9b26b222f20556227a53 ]
    
    Guillaume noticed that: for segments udp_queue_rcv_one_skb() returns the
    proto, and it should pass "ret" unmodified to ip_protocol_deliver_rcu().
    Otherwize, with a negtive value passed, it will underflow inet_protos.
    
    This can be reproduced with IPIP FOU:
    
      # ip fou add port 5555 ipproto 4
      # ethtool -K eth1 rx-gro-list on
    
    Fixes: cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")
    Reported-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7a756fc7cb9a93877d38bb1a968baad7067d03d
Author: Huazhong Tan <tanhuazhong@huawei.com>
Date:   Mon Dec 7 15:20:25 2020 +0800

    net: hns3: remove a misused pragma packed
    
    [ Upstream commit 61f54de2e9194f01874d5eda12037b0978e77519 ]
    
    hclge_dbg_reg_info[] is defined as an array of packed structure
    accidentally. However, this array contains pointers, which are
    no longer aligned naturally, and cannot be relocated on PPC64.
    Hence, when compile-testing this driver on PPC64 with
    CONFIG_RELOCATABLE=y (e.g. PowerPC allyesconfig), there will be
    some warnings.
    
    Since each field in structure hclge_qos_pri_map_cmd and
    hclge_dbg_bitmap_cmd is type u8, the pragma packed is unnecessary
    for these two structures as well, so remove the pragma packed in
    hclge_debugfs.h to fix this issue, and this increases
    hclge_dbg_reg_info[] by 4 bytes per entry.
    
    Fixes: a582b78dfc33 ("net: hns3: code optimization for debugfs related to "dump reg"")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ef23e860e765eb1dd287492206d833f04eae9df
Author: Stephen Suryaputra <ssuryaextr@gmail.com>
Date:   Thu Dec 3 22:06:04 2020 -0500

    vrf: packets with lladdr src needs dst at input with orig_iif when needs strict
    
    [ Upstream commit 205704c618af0ab2366015d2281a3b0814d918a0 ]
    
    Depending on the order of the routes to fe80::/64 are installed on the
    VRF table, the NS for the source link-local address of the originator
    might be sent to the wrong interface.
    
    This patch ensures that packets with link-local addr source is doing a
    lookup with the orig_iif when the destination addr indicates that it
    is strict.
    
    Add the reproducer as a use case in self test script fcnal-test.sh.
    
    Fixes: b4869aa2f881 ("net: vrf: ipv6 support for local traffic to local addresses")
    Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20201204030604.18828-1-ssuryaextr@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cae90bd22cffb1e19a83a794ad5f57dafb3e76ad
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:48:56 2020 +0800

    net: bridge: vlan: fix error return code in __vlan_add()
    
    [ Upstream commit ee4f52a8de2c6f78b01f10b4c330867d88c1653a ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: f8ed289fab84 ("bridge: vlan: use br_vlan_(get|put)_master to deal with refcounts")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Link: https://lore.kernel.org/r/1607071737-33875-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e6a15b0b3d412db935b56fc7854e2168d391db9
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 4 08:24:28 2020 -0800

    mac80211: mesh: fix mesh_pathtbl_init() error path
    
    [ Upstream commit 905b2032fa424f253d9126271439cc1db2b01130 ]
    
    If tbl_mpp can not be allocated, we call mesh_table_free(tbl_path)
    while tbl_path rhashtable has not yet been initialized, which causes
    panics.
    
    Simply factorize the rhashtable_init() call into mesh_table_alloc()
    
    WARNING: CPU: 1 PID: 8474 at kernel/workqueue.c:3040 __flush_work kernel/workqueue.c:3040 [inline]
    WARNING: CPU: 1 PID: 8474 at kernel/workqueue.c:3040 __cancel_work_timer+0x514/0x540 kernel/workqueue.c:3136
    Modules linked in:
    CPU: 1 PID: 8474 Comm: syz-executor663 Not tainted 5.10.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__flush_work kernel/workqueue.c:3040 [inline]
    RIP: 0010:__cancel_work_timer+0x514/0x540 kernel/workqueue.c:3136
    Code: 5d c3 e8 bf ae 29 00 0f 0b e9 f0 fd ff ff e8 b3 ae 29 00 0f 0b 43 80 3c 3e 00 0f 85 31 ff ff ff e9 34 ff ff ff e8 9c ae 29 00 <0f> 0b e9 dc fe ff ff 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c 7d fd ff
    RSP: 0018:ffffc9000165f5a0 EFLAGS: 00010293
    RAX: ffffffff814b7064 RBX: 0000000000000001 RCX: ffff888021c80000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff888024039ca0 R08: dffffc0000000000 R09: fffffbfff1dd3e64
    R10: fffffbfff1dd3e64 R11: 0000000000000000 R12: 1ffff920002cbebd
    R13: ffff888024039c88 R14: 1ffff11004807391 R15: dffffc0000000000
    FS:  0000000001347880(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000140 CR3: 000000002cc0a000 CR4: 00000000001506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     rhashtable_free_and_destroy+0x25/0x9c0 lib/rhashtable.c:1137
     mesh_table_free net/mac80211/mesh_pathtbl.c:69 [inline]
     mesh_pathtbl_init+0x287/0x2e0 net/mac80211/mesh_pathtbl.c:785
     ieee80211_mesh_init_sdata+0x2ee/0x530 net/mac80211/mesh.c:1591
     ieee80211_setup_sdata+0x733/0xc40 net/mac80211/iface.c:1569
     ieee80211_if_add+0xd5c/0x1cd0 net/mac80211/iface.c:1987
     ieee80211_add_iface+0x59/0x130 net/mac80211/cfg.c:125
     rdev_add_virtual_intf net/wireless/rdev-ops.h:45 [inline]
     nl80211_new_interface+0x563/0xb40 net/wireless/nl80211.c:3855
     genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
     genl_rcv_msg+0xe4e/0x1280 net/netlink/genetlink.c:800
     netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2494
     genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
     netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
     netlink_unicast+0x780/0x930 net/netlink/af_netlink.c:1330
     netlink_sendmsg+0x9a8/0xd40 net/netlink/af_netlink.c:1919
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg net/socket.c:671 [inline]
     ____sys_sendmsg+0x519/0x800 net/socket.c:2353
     ___sys_sendmsg net/socket.c:2407 [inline]
     __sys_sendmsg+0x2b1/0x360 net/socket.c:2440
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 60854fd94573 ("mac80211: mesh: convert path table to rhashtable")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
    Link: https://lore.kernel.org/r/20201204162428.2583119-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe6b822b335d3781ad466a7bbc3898abcd8d63e
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Dec 4 16:48:14 2020 +0800

    ipv4: fix error return code in rtm_to_fib_config()
    
    [ Upstream commit b410f04eb5b482b5efc4eee90de81ad35d3d923b ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: d15662682db2 ("ipv4: Allow ipv6 gateway with ipv4 routes")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/1607071695-33740-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b4f08f280154147b20437d14644804223bfbdcb
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Sat Aug 1 11:20:44 2020 -0400

    ptrace: Prevent kernel-infoleak in ptrace_get_syscall_info()
    
    commit 0032ce0f85a269a006e91277be5fdbc05fad8426 upstream.
    
    ptrace_get_syscall_info() is potentially copying uninitialized stack
    memory to userspace, since the compiler may leave a 3-byte hole near the
    beginning of `info`. Fix it by adding a padding field to `struct
    ptrace_syscall_info`.
    
    Fixes: 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Reviewed-by: Dmitry V. Levin <ldv@altlinux.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200801152044.230416-1-yepeilin.cs@gmail.com
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>