commit 2762b48e9611529239da2e68cba908dbbec9805f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 17 13:59:01 2021 +0100

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

commit 8f9a69a92fc63917c9bd921b28e3b2912980becf
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Mon Dec 14 22:07:39 2020 +0300

    net: drop bogus skb with CHECKSUM_PARTIAL and offset beyond end of trimmed packet
    
    commit 54970a2fbb673f090b7f02d7f57b10b2e0707155 upstream.
    
    syzbot reproduces BUG_ON in skb_checksum_help():
    tun creates (bogus) skb with huge partial-checksummed area and
    small ip packet inside. Then ip_rcv trims the skb based on size
    of internal ip packet, after that csum offset points beyond of
    trimmed skb. Then checksum_tg() called via netfilter hook
    triggers BUG_ON:
    
            offset = skb_checksum_start_offset(skb);
            BUG_ON(offset >= skb_headlen(skb));
    
    To work around the problem this patch forces pskb_trim_rcsum_slow()
    to return -EINVAL in described scenario. It allows its callers to
    drop such kind of packets.
    
    Link: https://syzkaller.appspot.com/bug?id=b419a5ca95062664fe1a60b764621eb4526e2cd0
    Reported-by: syzbot+7010af67ced6105e5ab6@syzkaller.appspotmail.com
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/1b2494af-2c56-8ee2-7bc0-923fcad1cdf8@virtuozzo.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45b5a900d51dadd5c269f2607db6dba97b70d3f7
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Dec 21 12:33:35 2020 +0800

    block: fix use-after-free in disk_part_iter_next
    
    commit aebf5db917055b38f4945ed6d621d9f07a44ff30 upstream.
    
    Make sure that bdgrab() is done on the 'block_device' instance before
    referring to it for avoiding use-after-free.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: syzbot+825f0f9657d4e528046e@syzkaller.appspotmail.com
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1493727066d8cf495242eccb43cf417e7b66a89
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Dec 10 08:30:59 2020 +0000

    KVM: arm64: Don't access PMCR_EL0 when no PMU is available
    
    commit 2a5f1b67ec577fb1544b563086e0377f095f88e2 upstream.
    
    We reset the guest's view of PMCR_EL0 unconditionally, based on
    the host's view of this register. It is however legal for an
    implementation not to provide any PMU, resulting in an UNDEF.
    
    The obvious fix is to skip the reset of this shadow register
    when no PMU is available, sidestepping the issue entirely.
    If no PMU is available, the guest is not able to request
    a virtual PMU anyway, so not doing nothing is the right thing
    to do!
    
    It is unlikely that this bug can hit any HW implementation
    though, as they all provide a PMU. It has been found using nested
    virt with the host KVM not implementing the PMU itself.
    
    Fixes: ab9468340d2bc ("arm64: KVM: Add access handler for PMCR register")
    Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20201210083059.1277162-1-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c630bc9ea81e390a9bf81408c275c1f424b1a32
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 3 22:36:23 2021 +0100

    wan: ds26522: select CONFIG_BITREVERSE
    
    commit 69931e11288520c250152180ecf9b6ac5e6e40ed upstream.
    
    Without this, the driver runs into a link failure
    
    arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe':
    slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table'
    arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table'
    arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write':
    slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table'
    
    Fixes: c37d4a0085c5 ("Maxim/driver: Add driver for maxim ds26522")
    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 27fefacdfd802b4504b811c291bec19765bf2b26
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Dec 28 16:48:40 2020 +0800

    net/mlx5e: Fix two double free cases
    
    commit 7a6eb072a9548492ead086f3e820e9aac71c7138 upstream.
    
    mlx5e_create_ttc_table_groups() frees ft->g on failure of
    kvzalloc(), but such failure will be caught by its caller
    in mlx5e_create_ttc_table() and ft->g will be freed again
    in mlx5e_destroy_flow_table(). The same issue also occurs
    in mlx5e_create_ttc_table_groups(). Set ft->g to NULL after
    kfree() to avoid double free.
    
    Fixes: 7b3722fa9ef6 ("net/mlx5e: Support RSS for GRE tunneled packets")
    Fixes: 33cfaaa8f36f ("net/mlx5e: Split the main flow steering table")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26cf873f3caab3b3d479795ab52cb1dbe350b66d
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Dec 21 19:27:31 2020 +0800

    net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups
    
    commit 5b0bb12c58ac7d22e05b5bfdaa30a116c8c32e32 upstream.
    
    When mlx5_create_flow_group() fails, ft->g should be
    freed just like when kvzalloc() fails. The caller of
    mlx5e_create_l2_table_groups() does not catch this
    issue on failure, which leads to memleak.
    
    Fixes: 33cfaaa8f36f ("net/mlx5e: Split the main flow steering table")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9f32688989125e8a7bbcbdc56992ebda9012be7
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Tue Jan 5 13:18:37 2021 +0800

    iommu/intel: Fix memleak in intel_irq_remapping_alloc
    
    commit ff2b46d7cff80d27d82f7f3252711f4ca1666129 upstream.
    
    When irq_domain_get_irq_data() or irqd_cfg() fails
    at i == 0, data allocated by kzalloc() has not been
    freed before returning, which leads to memleak.
    
    Fixes: b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20210105051837.32118-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55f0879f18e7c844028a5bc91120b31080ad8045
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 3 22:42:39 2021 +0100

    block: rsxx: select CONFIG_CRC32
    
    commit 36a106a4c1c100d55ba3d32a21ef748cfcd4fa99 upstream.
    
    Without crc32, the driver fails to link:
    
    arm-linux-gnueabi-ld: drivers/block/rsxx/config.o: in function `rsxx_load_config':
    config.c:(.text+0x124): undefined reference to `crc32_le'
    
    Fixes: 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca5a07fc092c93f29d4d6ab625de1652415a2967
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 3 22:36:20 2021 +0100

    wil6210: select CONFIG_CRC32
    
    commit e186620d7bf11b274b985b839c38266d7918cc05 upstream.
    
    Without crc32, the driver fails to link:
    
    arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o: in function `wil_fw_verify':
    fw.c:(.text+0x74c): undefined reference to `crc32_le'
    arm-linux-gnueabi-ld: drivers/net/wireless/ath/wil6210/fw.o:fw.c:(.text+0x758): more undefined references to `crc32_le' follow
    
    Fixes: 151a9706503f ("wil6210: firmware download")
    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 13271ebf8926c8988eb10d31fd2d928ec6018afd
Author: Shravya Kumbham <shravya.kumbham@xilinx.com>
Date:   Wed Dec 23 16:51:02 2020 +0530

    dmaengine: xilinx_dma: fix mixed_enum_type coverity warning
    
    commit 2d5efea64472469117dc1a9a39530069e95b21e9 upstream.
    
    Typecast the fls(width -1) with (enum dmaengine_alignment) in
    xilinx_dma_chan_probe function to fix the coverity warning.
    
    Addresses-Coverity: Event mixed_enum_type.
    Fixes: 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
    Signed-off-by: Shravya Kumbham <shravya.kumbham@xilinx.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Link: https://lore.kernel.org/r/1608722462-29519-4-git-send-email-radhey.shyam.pandey@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26955dd81889094235eed2f71bc1cff1d7d998ce
Author: Shravya Kumbham <shravya.kumbham@xilinx.com>
Date:   Wed Dec 23 16:51:00 2020 +0530

    dmaengine: xilinx_dma: check dma_async_device_register return value
    
    commit 99974aedbd73523969afb09f33c6e3047cd0ddae upstream.
    
    dma_async_device_register() can return non-zero error code. Add
    condition to check the return value of dma_async_device_register
    function and handle the error path.
    
    Addresses-Coverity: Event check_return.
    Fixes: 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
    Signed-off-by: Shravya Kumbham <shravya.kumbham@xilinx.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Link: https://lore.kernel.org/r/1608722462-29519-2-git-send-email-radhey.shyam.pandey@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed39233389591d939a1680388e4dbaac536a471d
Author: Roman Guskov <rguskov@dh-electronics.com>
Date:   Mon Dec 21 13:35:32 2020 +0100

    spi: stm32: FIFO threshold level - fix align packet size
    
    commit a590370d918fc66c62df6620445791fbe840344a upstream.
    
    if cur_bpw <= 8 and xfer_len < 4 then the value of fthlv will be 1 and
    SPI registers content may have been lost.
    
    * If SPI data register is accessed as a 16-bit register and DSIZE <= 8bit,
      better to select FTHLV = 2, 4, 6 etc
    
    * If SPI data register is accessed as a 32-bit register and DSIZE > 8bit,
      better to select FTHLV = 2, 4, 6 etc, while if DSIZE <= 8bit,
      better to select FTHLV = 4, 8, 12 etc
    
    Signed-off-by: Roman Guskov <rguskov@dh-electronics.com>
    Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller")
    Reviewed-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20201221123532.27272-1-rguskov@dh-electronics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4f18c95ae5d893385c117467130a88e8d87337a
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jan 5 10:19:57 2021 +0000

    cpufreq: powernow-k8: pass policy rather than use cpufreq_cpu_get()
    
    commit 943bdd0cecad06da8392a33093230e30e501eccc upstream.
    
    Currently there is an unlikely case where cpufreq_cpu_get() returns a
    NULL policy and this will cause a NULL pointer dereference later on.
    
    Fix this by passing the policy to transition_frequency_fidvid() from
    the caller and hence eliminating the need for the cpufreq_cpu_get()
    and cpufreq_cpu_put().
    
    Thanks to Viresh Kumar for suggesting the fix.
    
    Addresses-Coverity: ("Dereference null return")
    Fixes: b43a7ffbf33b ("cpufreq: Notify all policy->cpus in cpufreq_notify_transition()")
    Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d87acd7e4ac0df83d8c8bb445923c415bf7171a
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date:   Mon Dec 14 12:58:50 2020 +0800

    i2c: sprd: use a specific timeout to avoid system hang up issue
    
    commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream.
    
    If the i2c device SCL bus being pulled up due to some exception before
    message transfer done, the system cannot receive the completing interrupt
    signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
    jiffies eclipse, that would make the system seemed hang up. To avoid that
    happen, this patch adds a specific timeout for message transfer.
    
    Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
    Signed-off-by: Linhua Xu <linhua.xu@unisoc.com>
    Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
    [wsa: changed errno to ETIMEDOUT]
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c18eee29f080757a7ed964e53d1ccd643943c2a3
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Fri Dec 4 10:55:39 2020 +0100

    ARM: OMAP2+: omap_device: fix idling of devices during probe
    
    commit ec76c2eea903947202098090bbe07a739b5246e9 upstream.
    
    On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
    during probe of the second mmc used for wifi. Therefore
    omap_device_late_idle idled the device during probing causing oopses when
    accessing the registers.
    
    It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
    in the notifier callback. Therefore set od->_driver_status also in that
    case.
    
    This came apparent after commit 21b2cec61c04 ("mmc: Set
    PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4") causing this
    oops:
    
    omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver.  Idling
    8<--- cut here ---
    Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
    ...
    (omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258)
    (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0)
    (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c)
    (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84)
    (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0)
    (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98)
    (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)
    
    Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer")
    Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    [tony@atomide.com: left out extra parens, trimmed description stack trace]
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2adba0a6f7f29776f1120274e7114d2a17077755
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sat Nov 14 19:39:05 2020 +0100

    iio: imu: st_lsm6dsx: fix edge-trigger interrupts
    
    commit 3f9bce7a22a3f8ac9d885c9d75bc45569f24ac8b upstream
    
    If we are using edge IRQs, new samples can arrive while processing
    current interrupt since there are no hw guarantees the irq line
    stays "low" long enough to properly detect the new interrupt.
    In this case the new sample will be missed.
    Polling FIFO status register in st_lsm6dsx_handler_thread routine
    allow us to read new samples even if the interrupt arrives while
    processing previous data and the timeslot where the line is "low"
    is too short to be properly detected.
    
    Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts")
    Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    [sudip: manual backport to old irq handler path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59c238a019f50bf263fec8553349e3705f1bb6cb
Author: Sean Nyekjaer <sean@geanix.com>
Date:   Mon Jul 15 09:07:15 2019 +0200

    iio: imu: st_lsm6dsx: flip irq return logic
    
    commit ec76d918f23034f9f662539ca9c64e2ae3ba9fba upstream
    
    No need for using reverse logic in the irq return,
    fix this by flip things around.
    
    Signed-off-by: Sean Nyekjaer <sean@geanix.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 153f884fa15dcb9a7ffa5588b9656419bdbb3778
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:05 2020 +0100

    spi: pxa2xx: Fix use-after-free on unbind
    
    commit 5626308bb94d9f930aa5f7c77327df4c6daa7759 upstream
    
    pxa2xx_spi_remove() accesses the driver's private data after calling
    spi_unregister_controller() even though that function releases the last
    reference on the spi_controller and thereby frees the private data.
    
    Fix by switching over to the new devm_spi_alloc_master/slave() helper
    which keeps the private data accessible until the driver has unbound.
    
    Fixes: 32e5b57232c0 ("spi: pxa2xx: Fix controller unregister order")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v2.6.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v2.6.17+: 32e5b57232c0: spi: pxa2xx: Fix controller unregister order
    Cc: <stable@vger.kernel.org> # v2.6.17+
    Link: https://lore.kernel.org/r/5764b04d4a6e43069ebb7808f64c2f774ac6f193.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c3747b1a8b41a8b35e21071242bf6bd1e7b5203
Author: Richard Weinberger <richard@nod.at>
Date:   Mon Nov 16 22:05:30 2020 +0100

    ubifs: wbuf: Don't leak kernel memory to flash
    
    commit 20f1431160c6b590cdc269a846fc5a448abf5b98 upstream
    
    Write buffers use a kmalloc()'ed buffer, they can leak
    up to seven bytes of kernel memory to flash if writes are not
    aligned.
    So use ubifs_pad() to fill these gaps with padding bytes.
    This was never a problem while scanning because the scanner logic
    manually aligns node lengths and skips over these gaps.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [sudip: adjust context]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8746ab6ce5f321e3b33841078b2cf6bf3a63a89d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Dec 16 09:29:51 2020 +0000

    drm/i915: Fix mismatch between misplaced vma check and vma insert
    
    commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream
    
    When inserting a VMA, we restrict the placement to the low 4G unless the
    caller opts into using the full range. This was done to allow usersapce
    the opportunity to transition slowly from a 32b address space, and to
    avoid breaking inherent 32b assumptions of some commands.
    
    However, for insert we limited ourselves to 4G-4K, but on verification
    we allowed the full 4G. This causes some attempts to bind a new buffer
    to sporadically fail with -ENOSPC, but at other times be bound
    successfully.
    
    commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
    page") suggests that there is a genuine problem with stateless addressing
    that cannot utilize the last page in 4G and so we purposefully excluded
    it. This means that the quick pin pass may cause us to utilize a buggy
    placement.
    
    Reported-by: CQ Tang <cq.tang@intel.com>
    Testcase: igt/gem_exec_params/larger-than-life-batch
    Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: CQ Tang <cq.tang@intel.com>
    Reviewed-by: CQ Tang <cq.tang@intel.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Cc: <stable@vger.kernel.org> # v4.5+
    Link: https://patchwork.freedesktop.org/patch/msgid/20201216092951.7124-1-chris@chris-wilson.co.uk
    (cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    [sudip: use file from old path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6604415ccd675d13251a1f44a2887cbf68a28d1a
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri Aug 21 12:42:47 2020 -0700

    vmlinux.lds.h: Add PGO and AutoFDO input sections
    
    commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.
    
    Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
    
    When compiling with profiling information (collected via PGO
    instrumentations or AutoFDO sampling), Clang will separate code into
    .text.hot, .text.unlikely, or .text.unknown sections based on profiling
    information. After D79600 (clang-11), these sections will have a
    trailing `.` suffix, ie.  .text.hot., .text.unlikely., .text.unknown..
    
    When using -ffunction-sections together with profiling infomation,
    either explicitly (FGKASLR) or implicitly (LTO), code may be placed in
    sections following the convention:
    .text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz>
    where <foo>, <bar>, and <baz> are functions.  (This produces one section
    per function; we generally try to merge these all back via linker script
    so that we don't have 50k sections).
    
    For the above cases, we need to teach our linker scripts that such
    sections might exist and that we'd explicitly like them grouped
    together, otherwise we can wind up with code outside of the
    _stext/_etext boundaries that might not be mapped properly for some
    architectures, resulting in boot failures.
    
    If the linker script is not told about possible input sections, then
    where the section is placed as output is a heuristic-laiden mess that's
    non-portable between linkers (ie. BFD and LLD), and has resulted in many
    hard to debug bugs.  Kees Cook is working on cleaning this up by adding
    --orphan-handling=warn linker flag used in ARCH=powerpc to additional
    architectures. In the case of linker scripts, borrowing from the Zen of
    Python: explicit is better than implicit.
    
    Also, ld.bfd's internal linker script considers .text.hot AND
    .text.hot.* to be part of .text, as well as .text.unlikely and
    .text.unlikely.*. I didn't see support for .text.unknown.*, and didn't
    see Clang producing such code in our kernel builds, but I see code in
    LLVM that can produce such section names if profiling information is
    missing. That may point to a larger issue with generating or collecting
    profiles, but I would much rather be safe and explicit than have to
    debug yet another issue related to orphan section placement.
    
    Reported-by: Jian Cai <jiancai@google.com>
    Suggested-by: Fāng-ruì Sòng <maskray@google.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: Luis Lozano <llozano@google.com>
    Tested-by: Manoj Gupta <manojgupta@google.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Cc: linux-arch@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee
    Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655
    Link: https://reviews.llvm.org/D79600
    Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760
    Link: https://lore.kernel.org/r/20200821194310.3089815-7-keescook@chromium.org
    
    Debugged-by: Luis Lozano <llozano@google.com>
    [nc: Resolve small conflict due to lack of NOINSTR_TEXT]
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de5f040136be9300976b01634f8ce8a9e0ecba8e
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Mon Jan 11 15:12:58 2021 -0800

    x86/resctrl: Don't move a task to the same resource group
    
    commit a0195f314a25582b38993bf30db11c300f4f4611 upstream
    
    Shakeel Butt reported in [1] that a user can request a task to be moved
    to a resource group even if the task is already in the group. It just
    wastes time to do the move operation which could be costly to send IPI
    to a different CPU.
    
    Add a sanity check to ensure that the move operation only happens when
    the task is not already in the resource group.
    
    [1] https://lore.kernel.org/lkml/CALvZod7E9zzHwenzf7objzGKsdBmVwTgEJ0nPgs0LUFU3SN5Pw@mail.gmail.com/
    
    Backporting notes:
    
    Since upstream commit fa7d949337cc ("x86/resctrl: Rename and move rdt
    files to a separate directory"), the file
    arch/x86/kernel/cpu/intel_rdt_rdtgroup.c has been renamed and moved to
    arch/x86/kernel/cpu/resctrl/rdtgroup.c.
    Apply the change against file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
    for older stable trees.
    
    Fixes: e02737d5b826 ("x86/intel_rdt: Add tasks files")
    Reported-by: Shakeel Butt <shakeelb@google.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@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/962ede65d8e95be793cb61102cca37f7bb018e66.1608243147.git.reinette.chatre@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdb302f47dcaed6c9f37315bfd9292361e19f54b
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Mon Jan 11 15:12:28 2021 -0800

    x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR
    
    commit ae28d1aae48a1258bd09a6f707ebb4231d79a761 upstream
    
    Currently, when moving a task to a resource group the PQR_ASSOC MSR is
    updated with the new closid and rmid in an added task callback. If the
    task is running, the work is run as soon as possible. If the task is not
    running, the work is executed later in the kernel exit path when the
    kernel returns to the task again.
    
    Updating the PQR_ASSOC MSR as soon as possible on the CPU a moved task
    is running is the right thing to do. Queueing work for a task that is
    not running is unnecessary (the PQR_ASSOC MSR is already updated when
    the task is scheduled in) and causing system resource waste with the way
    in which it is implemented: Work to update the PQR_ASSOC register is
    queued every time the user writes a task id to the "tasks" file, even if
    the task already belongs to the resource group.
    
    This could result in multiple pending work items associated with a
    single task even if they are all identical and even though only a single
    update with most recent values is needed. Specifically, even if a task
    is moved between different resource groups while it is sleeping then it
    is only the last move that is relevant but yet a work item is queued
    during each move.
    
    This unnecessary queueing of work items could result in significant
    system resource waste, especially on tasks sleeping for a long time.
    For example, as demonstrated by Shakeel Butt in [1] writing the same
    task id to the "tasks" file can quickly consume significant memory. The
    same problem (wasted system resources) occurs when moving a task between
    different resource groups.
    
    As pointed out by Valentin Schneider in [2] there is an additional issue
    with the way in which the queueing of work is done in that the task_struct
    update is currently done after the work is queued, resulting in a race with
    the register update possibly done before the data needed by the update is
    available.
    
    To solve these issues, update the PQR_ASSOC MSR in a synchronous way
    right after the new closid and rmid are ready during the task movement,
    only if the task is running. If a moved task is not running nothing
    is done since the PQR_ASSOC MSR will be updated next time the task is
    scheduled. This is the same way used to update the register when tasks
    are moved as part of resource group removal.
    
    [1] https://lore.kernel.org/lkml/CALvZod7E9zzHwenzf7objzGKsdBmVwTgEJ0nPgs0LUFU3SN5Pw@mail.gmail.com/
    [2] https://lore.kernel.org/lkml/20201123022433.17905-1-valentin.schneider@arm.com
    
     [ bp: Massage commit message and drop the two update_task_closid_rmid()
       variants. ]
    
    Backporting notes:
    
    Since upstream commit fa7d949337cc ("x86/resctrl: Rename and move rdt
    files to a separate directory"), the file
    arch/x86/kernel/cpu/intel_rdt_rdtgroup.c has been renamed and moved to
    arch/x86/kernel/cpu/resctrl/rdtgroup.c.
    Apply the change against file arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
    for older stable trees.
    
    Since upstream commit 352940ececaca ("x86/resctrl: Rename the RDT
    functions and definitions"), resctrl functions received more generic
    names. Specifically related to this backport, intel_rdt_sched_in()
    was renamed to rescrl_sched_in().
    
    Fixes: e02737d5b826 ("x86/intel_rdt: Add tasks files")
    Reported-by: Shakeel Butt <shakeelb@google.com>
    Reported-by: Valentin Schneider <valentin.schneider@arm.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Reviewed-by: James Morse <james.morse@arm.com>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/17aa2fb38fc12ce7bb710106b3e7c7b45acb9e94.1608243147.git.reinette.chatre@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0baf49b487a0054c07507591c9c95fd7274c0e0a
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jan 6 00:15:22 2021 +0100

    net: fix pmtu check in nopmtudisc mode
    
    [ Upstream commit 50c661670f6a3908c273503dfa206dfc7aa54c07 ]
    
    For some reason ip_tunnel insist on setting the DF bit anyway when the
    inner header has the DF bit set, EVEN if the tunnel was configured with
    'nopmtudisc'.
    
    This means that the script added in the previous commit
    cannot be made to work by adding the 'nopmtudisc' flag to the
    ip tunnel configuration. Doing so breaks connectivity even for the
    without-conntrack/netfilter scenario.
    
    When nopmtudisc is set, the tunnel will skip the mtu check, so no
    icmp error is sent to client. Then, because inner header has DF set,
    the outer header gets added with DF bit set as well.
    
    IP stack then sends an error to itself because the packet exceeds
    the device MTU.
    
    Fixes: 23a3647bc4f93 ("ip_tunnels: Use skb-len to PMTU check.")
    Cc: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98e7abff10db3c791e133a45bc40d83f64ac4e70
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jan 6 00:15:23 2021 +0100

    net: ip: always refragment ip defragmented packets
    
    [ Upstream commit bb4cc1a18856a73f0ff5137df0c2a31f4c50f6cf ]
    
    Conntrack reassembly records the largest fragment size seen in IPCB.
    However, when this gets forwarded/transmitted, fragmentation will only
    be forced if one of the fragmented packets had the DF bit set.
    
    In that case, a flag in IPCB will force fragmentation even if the
    MTU is large enough.
    
    This should work fine, but this breaks with ip tunnels.
    Consider client that sends a UDP datagram of size X to another host.
    
    The client fragments the datagram, so two packets, of size y and z, are
    sent. DF bit is not set on any of these packets.
    
    Middlebox netfilter reassembles those packets back to single size-X
    packet, before routing decision.
    
    packet-size-vs-mtu checks in ip_forward are irrelevant, because DF bit
    isn't set.  At output time, ip refragmentation is skipped as well
    because x is still smaller than the mtu of the output device.
    
    If ttransmit device is an ip tunnel, the packet size increases to
    x+overhead.
    
    Also, tunnel might be configured to force DF bit on outer header.
    
    In this case, packet will be dropped (exceeds MTU) and an ICMP error is
    generated back to sender.
    
    But sender already respects the announced MTU, all the packets that
    it sent did fit the announced mtu.
    
    Force refragmentation as per original sizes unconditionally so ip tunnel
    will encapsulate the fragments instead.
    
    The only other solution I see is to place ip refragmentation in
    the ip_tunnel code to handle this case.
    
    Fixes: d6b915e29f4ad ("ip_fragment: don't forward defragmented DF packet")
    Reported-by: Christian Perle <christian.perle@secunet.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8b4552e300762727318a1a8a78e4dc8ffe5138
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Dec 30 19:40:27 2020 -0800

    net: vlan: avoid leaks on register_vlan_dev() failures
    
    [ Upstream commit 55b7ab1178cbf41f979ff83236d3321ad35ed2ad ]
    
    VLAN checks for NETREG_UNINITIALIZED to distinguish between
    registration failure and unregistration in progress.
    
    Since commit cb626bf566eb ("net-sysfs: Fix reference count leak")
    registration failure may, however, result in NETREG_UNREGISTERED
    as well as NETREG_UNINITIALIZED.
    
    This fix is similer to cebb69754f37 ("rtnetlink: Fix
    memory(net_device) leak when ->newlink fails")
    
    Fixes: cb626bf566eb ("net-sysfs: Fix reference count leak")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51d3a640509a8c3d1ba6efd1b42d3344d4ef5b75
Author: Jouni K. Seppänen <jks@iki.fi>
Date:   Tue Jan 5 06:52:49 2021 +0200

    net: cdc_ncm: correct overhead in delayed_ndp_size
    
    [ Upstream commit 7a68d725e4ea384977445e0bcaed3d7de83ab5b3 ]
    
    Aligning to tx_ndp_modulus is not sufficient because the next align
    call can be cdc_ncm_align_tail, which can add up to ctx->tx_modulus +
    ctx->tx_remainder - 1 bytes. This used to lead to occasional crashes
    on a Huawei 909s-120 LTE module as follows:
    
    - the condition marked /* if there is a remaining skb [...] */ is true
      so the swaps happen
    - skb_out is set from ctx->tx_curr_skb
    - skb_out->len is exactly 0x3f52
    - ctx->tx_curr_size is 0x4000 and delayed_ndp_size is 0xac
      (note that the sum of skb_out->len and delayed_ndp_size is 0x3ffe)
    - the for loop over n is executed once
    - the cdc_ncm_align_tail call marked /* align beginning of next frame */
      increases skb_out->len to 0x3f56 (the sum is now 0x4002)
    - the condition marked /* check if we had enough room left [...] */ is
      false so we break out of the loop
    - the condition marked /* If requested, put NDP at end of frame. */ is
      true so the NDP is written into skb_out
    - now skb_out->len is 0x4002, so padding_count is minus two interpreted
      as an unsigned number, which is used as the length argument to memset,
      leading to a crash with various symptoms but usually including
    
    > Call Trace:
    >  <IRQ>
    >  cdc_ncm_fill_tx_frame+0x83a/0x970 [cdc_ncm]
    >  cdc_mbim_tx_fixup+0x1d9/0x240 [cdc_mbim]
    >  usbnet_start_xmit+0x5d/0x720 [usbnet]
    
    The cdc_ncm_align_tail call first aligns on a ctx->tx_modulus
    boundary (adding at most ctx->tx_modulus-1 bytes), then adds
    ctx->tx_remainder bytes. Alternatively, the next alignment call can
    occur in cdc_ncm_ndp16 or cdc_ncm_ndp32, in which case at most
    ctx->tx_ndp_modulus-1 bytes are added.
    
    A similar problem has occurred before, and the code is nontrivial to
    reason about, so add a guard before the crashing call. By that time it
    is too late to prevent any memory corruption (we'll have written past
    the end of the buffer already) but we can at least try to get a warning
    written into an on-disk log by avoiding the hard crash caused by padding
    past the buffer with a huge number of zeros.
    
    Signed-off-by: Jouni K. Seppänen <jks@iki.fi>
    Fixes: 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end of NCM frame")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=209407
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d98c9412b6688b8335f105e1f78ae1acfd1f8134
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Wed Jan 13 07:12:44 2021 +0000

    powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
    
    [ Upstream commit d85be8a49e733dcd23674aa6202870d54bf5600d ]
    
    The placeholder for instruction selection should use the second
    argument's operand, which is %1, not %0. This could generate incorrect
    assembly code if the memory addressing of operand %0 is a different
    form from that of operand %1.
    
    Also remove the %Un placeholder because having %Un placeholders
    for two operands which are based on the same local var (ptep) doesn't
    make much sense. By the way, it doesn't change the current behaviour
    because "<>" constraint is missing for the associated "=m".
    
    [chleroy: revised commit log iaw segher's comments and removed %U0]
    
    Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
    Cc: <stable@vger.kernel.org> # v2.6.28+
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>