commit e98f3c4269fda898b913259a7d9b60fb38269869
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Nov 10 10:29:08 2020 +0100

    Linux 4.14.205
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20201109125016.734107741@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45a861d60d1edc8011a4a8c2c26149119aeeb3a6
Author: Tomasz Maciej Nowak <tmn505@gmail.com>
Date:   Thu Feb 27 17:52:32 2020 +0100

    arm64: dts: marvell: espressobin: add ethernet alias
    
    commit 5253cb8c00a6f4356760efb38bca0e0393aa06de upstream.
    
    The maker of this board and its variants, stores MAC address in U-Boot
    environment. Add alias for bootloader to recognise, to which ethernet
    node inject the factory MAC address.
    
    Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    [pali: Backported to 4.14]
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50e050fb05ceaabb68064a11da44af52b6c423cd
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Oct 22 17:38:22 2020 +0200

    PM: runtime: Resume the device earlier in __device_release_driver()
    
    commit 9226c504e364158a17a68ff1fe9d67d266922f50 upstream.
    
    Since the device is resumed from runtime-suspend in
    __device_release_driver() anyway, it is better to do that before
    looking for busy managed device links from it to consumers, because
    if there are any, device_links_unbind_consumers() will be called
    and it will cause the consumer devices' drivers to unbind, so the
    consumer devices will be runtime-resumed.  In turn, resuming each
    consumer device will cause the supplier to be resumed and when the
    runtime PM references from the given consumer to it are dropped, it
    may be suspended.  Then, the runtime-resume of the next consumer
    will cause the supplier to resume again and so on.
    
    Update the code accordingly.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
    Cc: All applicable <stable@vger.kernel.org> # All applicable
    Tested-by: Xiang Chen <chenxiang66@hisilicon.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31dff3ab42b599a9d4ccb3798c99eaea9ad261a5
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Mon Oct 19 19:19:57 2020 -0700

    Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"
    
    This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729.
    (but only from 5.2 and prior kernels)
    
    The original commit was a preventive fix based on code-review and was
    auto-picked for stable back-port (for better or worse).
    It was OK for v5.3+ kernels, but turned up needing an implicit change
    68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have
     exception cause)" merged in v5.3 which itself was not backported.
    So to summarize the stable backport of this patch for v5.2 and prior
    kernels is busted and it won't boot.
    
    The obvious solution is backport 68e5c6f073bcf70 but that is a pain as
    it doesn't revert cleanly and each of affected kernels (so far v4.19,
    v4.14, v4.9, v4.4) needs a slightly different massaged varaint.
    So the easier fix is to simply revert the backport from 5.2 and prior.
    The issue was not a big deal as it would cause strace to sporadically
    not work correctly.
    
    Waldemar Brodkorb first reported this when running ARC uClibc regressions
    on latest stable kernels (with offending backport). Once he bisected it,
    the analysis was trivial, so thx to him for this.
    
    Reported-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
    Bisected-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
    Cc: stable <stable@vger.kernel.org> # 5.2 and prior
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3479f5c38a52bc880a94ea6a0ec2f537eab5bf5
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Tue Oct 27 15:01:17 2020 -0700

    ARC: stack unwinding: avoid indefinite looping
    
    commit 328d2168ca524d501fc4b133d6be076142bd305c upstream.
    
    Currently stack unwinder is a while(1) loop which relies on the dwarf
    unwinder to signal termination, which in turn relies on dwarf info to do
    so. This in theory could cause an infinite loop if the dwarf info was
    somehow messed up or the register contents were etc.
    
    This fix thus detects the excessive looping and breaks the loop.
    
    | Mem: 26184K used, 1009136K free, 0K shrd, 0K buff, 14416K cached
    | CPU:  0.0% usr 72.8% sys  0.0% nic 27.1% idle  0.0% io  0.0% irq  0.0% sirq
    | Load average: 4.33 2.60 1.11 2/74 139
    |   PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    |   133     2 root     SWN      0  0.0   3 22.9 [rcu_torture_rea]
    |   132     2 root     SWN      0  0.0   0 22.0 [rcu_torture_rea]
    |   131     2 root     SWN      0  0.0   3 21.5 [rcu_torture_rea]
    |   126     2 root     RW       0  0.0   2  5.4 [rcu_torture_wri]
    |   129     2 root     SWN      0  0.0   0  0.2 [rcu_torture_fak]
    |   137     2 root     SW       0  0.0   0  0.2 [rcu_torture_cbf]
    |   127     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   138   115 root     R     1464  0.1   2  0.1 top
    |   130     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   128     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   115     1 root     S     1472  0.1   1  0.0 -/bin/sh
    |   104     1 root     S     1464  0.1   0  0.0 inetd
    |     1     0 root     S     1456  0.1   2  0.0 init
    |    78     1 root     S     1456  0.1   0  0.0 syslogd -O /var/log/messages
    |   134     2 root     SW       0  0.0   2  0.0 [rcu_torture_sta]
    |    10     2 root     IW       0  0.0   1  0.0 [rcu_preempt]
    |    88     2 root     IW       0  0.0   1  0.0 [kworker/1:1-eve]
    |    66     2 root     IW       0  0.0   2  0.0 [kworker/2:2-eve]
    |    39     2 root     IW       0  0.0   2  0.0 [kworker/2:1-eve]
    | unwinder looping too long, aborting !
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f395f62a01227986830748aa2b7e046553989d13
Author: Macpaul Lin <macpaul.lin@mediatek.com>
Date:   Fri Nov 6 13:54:29 2020 +0800

    usb: mtu3: fix panic in mtu3_gadget_stop()
    
    commit 20914919ad31849ee2b9cfe0428f4a20335c9e2a upstream.
    
    This patch fixes a possible issue when mtu3_gadget_stop()
    already assigned NULL to mtu->gadget_driver during mtu_gadget_disconnect().
    
    [<ffffff9008161974>] notifier_call_chain+0xa4/0x128
    [<ffffff9008161fd4>] __atomic_notifier_call_chain+0x84/0x138
    [<ffffff9008162ec0>] notify_die+0xb0/0x120
    [<ffffff900809e340>] die+0x1f8/0x5d0
    [<ffffff90080d03b4>] __do_kernel_fault+0x19c/0x280
    [<ffffff90080d04dc>] do_bad_area+0x44/0x140
    [<ffffff90080d0f9c>] do_translation_fault+0x4c/0x90
    [<ffffff9008080a78>] do_mem_abort+0xb8/0x258
    [<ffffff90080849d0>] el1_da+0x24/0x3c
    [<ffffff9009bde01c>] mtu3_gadget_disconnect+0xac/0x128
    [<ffffff9009bd576c>] mtu3_irq+0x34c/0xc18
    [<ffffff90082ac03c>] __handle_irq_event_percpu+0x2ac/0xcd0
    [<ffffff90082acae0>] handle_irq_event_percpu+0x80/0x138
    [<ffffff90082acc44>] handle_irq_event+0xac/0x148
    [<ffffff90082b71cc>] handle_fasteoi_irq+0x234/0x568
    [<ffffff90082a8708>] generic_handle_irq+0x48/0x68
    [<ffffff90082a96ac>] __handle_domain_irq+0x264/0x1740
    [<ffffff90080819f4>] gic_handle_irq+0x14c/0x250
    [<ffffff9008084cec>] el1_irq+0xec/0x194
    [<ffffff90085b985c>] dma_pool_alloc+0x6e4/0xae0
    [<ffffff9008d7f890>] cmdq_mbox_pool_alloc_impl+0xb0/0x238
    [<ffffff9008d80904>] cmdq_pkt_alloc_buf+0x2dc/0x7c0
    [<ffffff9008d80f60>] cmdq_pkt_add_cmd_buffer+0x178/0x270
    [<ffffff9008d82320>] cmdq_pkt_perf_begin+0x108/0x148
    [<ffffff9008d824d8>] cmdq_pkt_create+0x178/0x1f0
    [<ffffff9008f96230>] mtk_crtc_config_default_path+0x328/0x7a0
    [<ffffff90090246cc>] mtk_drm_idlemgr_kick+0xa6c/0x1460
    [<ffffff9008f9bbb4>] mtk_drm_crtc_atomic_begin+0x1a4/0x1a68
    [<ffffff9008e8df9c>] drm_atomic_helper_commit_planes+0x154/0x878
    [<ffffff9008f2fb70>] mtk_atomic_complete.isra.16+0xe80/0x19c8
    [<ffffff9008f30910>] mtk_atomic_commit+0x258/0x898
    [<ffffff9008ef142c>] drm_atomic_commit+0xcc/0x108
    [<ffffff9008ef7cf0>] drm_mode_atomic_ioctl+0x1c20/0x2580
    [<ffffff9008ebc768>] drm_ioctl_kernel+0x118/0x1b0
    [<ffffff9008ebcde8>] drm_ioctl+0x5c0/0x920
    [<ffffff900863b030>] do_vfs_ioctl+0x188/0x1820
    [<ffffff900863c754>] SyS_ioctl+0x8c/0xa0
    
    Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver")
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1604642069-20961-1-git-send-email-macpaul.lin@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 236cd37d9f9af6dea682cf79a96a546d893d9dfb
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Nov 2 09:58:21 2020 -0500

    USB: Add NO_LPM quirk for Kingston flash drive
    
    commit afaa2e745a246c5ab95103a65b1ed00101e1bc63 upstream.
    
    In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston
    flash drive spontaneously disconnects and reconnects, over and over.
    Testing revealed that disabling Link Power Management for the drive
    fixed the problem.
    
    This patch adds a quirk entry for that drive to turn off LPM permanently.
    
    CC: Hans de Goede <jwrdegoede@fedoraproject.org>
    CC: <stable@vger.kernel.org>
    Reported-and-tested-by: Julien Humbert <julroy67@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb5b682cfbae466dfd02c3c4d25fc7b3ef5b1e8d
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Nov 3 13:44:25 2020 +0100

    USB: serial: option: add Telit FN980 composition 0x1055
    
    commit db0362eeb22992502764e825c79b922d7467e0eb upstream.
    
    Add the following Telit FN980 composition:
    
    0x1055: tty, adb, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20201103124425.12940-1-dnlplm@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3d90830aadd93051eed9d20942d578735038f94
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Sat Oct 31 23:54:58 2020 +0100

    USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231
    
    commit 489979b4aab490b6b917c11dc02d81b4b742784a upstream.
    
    Add following Telit LE910Cx compositions:
    
    0x1203: rndis, tty, adb, tty, tty, tty, tty
    0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty
    0x1231: rndis, tty, adb, audio, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20201031225458.10512-1-dnlplm@gmail.com
    [ johan: add comments after entries ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0949bb6fad356d7cd90963c379a4dffee65f5603
Author: Ziyi Cao <kernel@septs.pw>
Date:   Tue Oct 20 00:08:06 2020 +0800

    USB: serial: option: add Quectel EC200T module support
    
    commit a46b973bced1ba57420752bf38426acd9f6cbfa6 upstream.
    
    Add usb product id of the Quectel EC200T module.
    
    Signed-off-by: Ziyi Cao <kernel@septs.pw>
    Link: https://lore.kernel.org/r/17f8a2a3-ce0f-4be7-8544-8fdf286907d0@www.fastmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 005aa2b4848e666a7849a944f901f14b21647918
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 26 09:25:48 2020 +0100

    USB: serial: cyberjack: fix write-URB completion race
    
    commit 985616f0457d9f555fff417d0da56174f70cc14f upstream.
    
    The write-URB busy flag was being cleared before the completion handler
    was done with the URB, something which could lead to corrupt transfers
    due to a racing write request if the URB is resubmitted.
    
    Fixes: 507ca9bc0476 ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.")
    Cc: stable <stable@vger.kernel.org>     # 2.6.13
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be96acc7c1f6b1810d37382bfc3b57621d79972a
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 3 16:49:42 2020 +0800

    serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init
    
    commit 0c5fc92622ed5531ff324b20f014e9e3092f0187 upstream.
    
    Add the missing platform_driver_unregister() before return
    from serial_txx9_init in the error handling case when failed
    to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI
    defined.
    
    Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/")
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27b5a84801319e59e488fc830fe0d9fbddf03ae6
Author: Claire Chang <tientzu@chromium.org>
Date:   Mon Nov 2 20:07:49 2020 +0800

    serial: 8250_mtk: Fix uart_get_baud_rate warning
    
    commit 912ab37c798770f21b182d656937072b58553378 upstream.
    
    Mediatek 8250 port supports speed higher than uartclk / 16. If the baud
    rates in both the new and the old termios setting are higher than
    uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered.
    Passing NULL as the old termios so uart_get_baud_rate() will use
    uartclk / 16 - 1 as the new baud rate which will be replaced by the
    original baud rate later by tty_termios_encode_baud_rate() in
    mtk8250_set_termios().
    
    Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping")
    Signed-off-by: Claire Chang <tientzu@chromium.org>
    Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee55b8c6bf4d59c7b82079b8a7d67597bb3a5539
Author: Eddy Wu <itseddy0402@gmail.com>
Date:   Sat Nov 7 14:47:22 2020 +0800

    fork: fix copy_process(CLONE_PARENT) race with the exiting ->real_parent
    
    commit b4e00444cab4c3f3fec876dc0cccc8cbb0d1a948 upstream.
    
    current->group_leader->exit_signal may change during copy_process() if
    current->real_parent exits.
    
    Move the assignment inside tasklist_lock to avoid the race.
    
    Signed-off-by: Eddy Wu <eddy_wu@trendmicro.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9421bad22e9fb7f513d81ef8fec513c8a4850c0d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Nov 8 16:38:06 2020 +0100

    vt: Disable KD_FONT_OP_COPY
    
    commit 3c4e0dff2095c579b142d5a0693257f1c58b4804 upstream.
    
    It's buggy:
    
    On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote:
    > We recently discovered a slab-out-of-bounds read in fbcon in the latest
    > kernel ( v5.10-rc2 for now ).  The root cause of this vulnerability is that
    > "fbcon_do_set_font" did not handle "vc->vc_font.data" and
    > "vc->vc_font.height" correctly, and the patch
    > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this
    > issue.
    >
    > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and
    > use  KD_FONT_OP_SET again to set a large font.height for tty1. After that,
    > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data
    > in "fbcon_do_set_font", while tty1 retains the original larger
    > height. Obviously, this will cause an out-of-bounds read, because we can
    > access a smaller vc_font.data with a larger vc_font.height.
    
    Further there was only one user ever.
    - Android's loadfont, busybox and console-tools only ever use OP_GET
      and OP_SET
    - fbset documentation only mentions the kernel cmdline font: option,
      not anything else.
    - systemd used OP_COPY before release 232 published in Nov 2016
    
    Now unfortunately the crucial report seems to have gone down with
    gmane, and the commit message doesn't say much. But the pull request
    hints at OP_COPY being broken
    
    https://github.com/systemd/systemd/pull/3651
    
    So in other words, this never worked, and the only project which
    foolishly every tried to use it, realized that rather quickly too.
    
    Instead of trying to fix security issues here on dead code by adding
    missing checks, fix the entire thing by removing the functionality.
    
    Note that systemd code using the OP_COPY function ignored the return
    value, so it doesn't matter what we're doing here really - just in
    case a lone server somewhere happens to be extremely unlucky and
    running an affected old version of systemd. The relevant code from
    font_copy_to_all_vcs() in systemd was:
    
            /* copy font from active VT, where the font was uploaded to */
            cfo.op = KD_FONT_OP_COPY;
            cfo.height = vcs.v_active-1; /* tty1 == index 0 */
            (void) ioctl(vcfd, KDFONTOP, &cfo);
    
    Note this just disables the ioctl, garbage collecting the now unused
    callbacks is left for -next.
    
    v2: Tetsuo found the old mail, which allowed me to find it on another
    archive. Add the link too.
    
    Acked-by: Peilin Ye <yepeilin.cs@gmail.com>
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html
    References: https://github.com/systemd/systemd/pull/3651
    Cc: Greg KH <greg@kroah.com>
    Cc: Peilin Ye <yepeilin.cs@gmail.com>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c02d3dece1393bca8cdfe566989f64599178a18f
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Oct 27 21:49:01 2020 +0800

    ACPI: NFIT: Fix comparison to '-ENXIO'
    
    [ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]
    
    Initial value of rc is '-ENXIO', and we should
    use the initial value to check it.
    
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    [ rjw: Subject edit ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25b349b4d8229209266f5dd87744bafad2306bbc
Author: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Date:   Tue Oct 27 13:14:42 2020 +0900

    drm/vc4: drv: Add error handding for bind
    
    [ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ]
    
    There is a problem that if vc4_drm bind fails, a memory leak occurs on
    the drm_property_create side. Add error handding for drm_mode_config.
    
    Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7b611701f71863959b439d0db0245faf1f321bc
Author: Jeff Vander Stoep <jeffv@google.com>
Date:   Fri Oct 23 16:37:57 2020 +0200

    vsock: use ns_capable_noaudit() on socket create
    
    [ Upstream commit af545bb5ee53f5261db631db2ac4cde54038bdaf ]
    
    During __vsock_create() CAP_NET_ADMIN is used to determine if the
    vsock_sock->trusted should be set to true. This value is used later
    for determing if a remote connection should be allowed to connect
    to a restricted VM. Unfortunately, if the caller doesn't have
    CAP_NET_ADMIN, an audit message such as an selinux denial is
    generated even if the caller does not want a trusted socket.
    
    Logging errors on success is confusing. To avoid this, switch the
    capable(CAP_NET_ADMIN) check to the noaudit version.
    
    Reported-by: Roman Kiryanov <rkir@google.com>
    https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/
    Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
    Reviewed-by: James Morris <jamorris@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 301865a2ea2e636fe3eb67f86de12f0d8a6999e5
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Oct 10 11:25:39 2020 +0800

    scsi: core: Don't start concurrent async scan on same host
    
    [ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ]
    
    The current scanning mechanism is supposed to fall back to a synchronous
    host scan if an asynchronous scan is in progress. However, this rule isn't
    strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when
    checking shost->async_scan. When scsi_scan_host() is called concurrently,
    two async scans on same host can be started and a hang in do_scan_async()
    is observed.
    
    Fixes this issue by checking & setting shost->async_scan atomically with
    shost->scan_mutex.
    
    Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Ewan D. Milne <emilne@redhat.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2aafc54b8ed907134489d87ee44acbfb4bf858f2
Author: Gabriel Krisman Bertazi <krisman@collabora.com>
Date:   Thu Oct 22 16:58:42 2020 -0400

    blk-cgroup: Pre-allocate tree node on blkg_conf_prep
    
    [ Upstream commit f255c19b3ab46d3cad3b1b2e1036f4c926cb1d0c ]
    
    Similarly to commit 457e490f2b741 ("blkcg: allocate struct blkcg_gq
    outside request queue spinlock"), blkg_create can also trigger
    occasional -ENOMEM failures at the radix insertion because any
    allocation inside blkg_create has to be non-blocking, making it more
    likely to fail.  This causes trouble for userspace tools trying to
    configure io weights who need to deal with this condition.
    
    This patch reduces the occurrence of -ENOMEMs on this path by preloading
    the radix tree element on a GFP_KERNEL context, such that we guarantee
    the later non-blocking insertion won't fail.
    
    A similar solution exists in blkcg_init_queue for the same situation.
    
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 928f81df69eb1edda87c97046d6f3491192591db
Author: Gabriel Krisman Bertazi <krisman@collabora.com>
Date:   Thu Oct 22 16:58:41 2020 -0400

    blk-cgroup: Fix memleak on error path
    
    [ Upstream commit 52abfcbd57eefdd54737fc8c2dc79d8f46d4a3e5 ]
    
    If new_blkg allocation raced with blk_policy change and
    blkg_lookup_check fails, new_blkg is leaked.
    
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c59d7a4612e0909c3557c23017f5e4db7963e631
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Oct 21 11:53:59 2020 +0200

    of: Fix reserved-memory overlap detection
    
    [ Upstream commit ca05f33316559a04867295dd49f85aeedbfd6bfd ]
    
    The reserved-memory overlap detection code fails to detect overlaps if
    either of the regions starts at address 0x0.  The code explicitly checks
    for and ignores such regions, apparently in order to ignore dynamically
    allocated regions which have an address of 0x0 at this point.  These
    dynamically allocated regions also have a size of 0x0 at this point, so
    fix this by removing the check and sorting the dynamically allocated
    regions ahead of any static regions at address 0x0.
    
    For example, there are two overlaps in this case but they are not
    currently reported:
    
            foo@0 {
                    reg = <0x0 0x2000>;
            };
    
            bar@0 {
                    reg = <0x0 0x1000>;
            };
    
            baz@1000 {
                    reg = <0x1000 0x1000>;
            };
    
            quux {
                    size = <0x1000>;
            };
    
    but they are after this patch:
    
     OF: reserved mem: OVERLAP DETECTED!
     bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000)
     OF: reserved mem: OVERLAP DETECTED!
     foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000)
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b8af3ff5fcc4440b31b69910b92fc1b987373a9
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Oct 14 17:24:28 2020 +0800

    x86/kexec: Use up-to-dated screen_info copy to fill boot params
    
    [ Upstream commit afc18069a2cb7ead5f86623a5f3d4ad6e21f940d ]
    
    kexec_file_load() currently reuses the old boot_params.screen_info,
    but if drivers have change the hardware state, boot_param.screen_info
    could contain invalid info.
    
    For example, the video type might be no longer VGA, or the frame buffer
    address might be changed. If the kexec kernel keeps using the old screen_info,
    kexec'ed kernel may attempt to write to an invalid framebuffer
    memory region.
    
    There are two screen_info instances globally available, boot_params.screen_info
    and screen_info. Later one is a copy, and is updated by drivers.
    
    So let kexec_file_load use the updated copy.
    
    [ mingo: Tidied up the changelog. ]
    
    Signed-off-by: Kairui Song <kasong@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bee79d9066b667a2210805900366ccf73f395ce6
Author: Clément Péron <peron.clem@gmail.com>
Date:   Sat Oct 3 12:03:32 2020 +0200

    ARM: dts: sun4i-a10: fix cpu_alert temperature
    
    [ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ]
    
    When running dtbs_check thermal_zone warn about the
    temperature declared.
    
    thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000
    
    It's indeed wrong the real value is 85°C and not 850°C.
    
    Signed-off-by: Clément Péron <peron.clem@gmail.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 891f3eb413ac7d4d5a0c1c033a4700357fe2ae1a
Author: Mike Galbraith <efault@gmx.de>
Date:   Wed Nov 4 16:12:44 2020 +0100

    futex: Handle transient "ownerless" rtmutex state correctly
    
    commit 9f5d1c336a10c0d24e83e40b4c1b9539f7dba627 upstream.
    
    Gratian managed to trigger the BUG_ON(!newowner) in fixup_pi_state_owner().
    This is one possible chain of events leading to this:
    
    Task Prio       Operation
    T1   120        lock(F)
    T2   120        lock(F)   -> blocks (top waiter)
    T3   50 (RT)    lock(F)   -> boosts T1 and blocks (new top waiter)
    XX              timeout/  -> wakes T2
                    signal
    T1   50         unlock(F) -> wakes T3 (rtmutex->owner == NULL, waiter bit is set)
    T2   120        cleanup   -> try_to_take_mutex() fails because T3 is the top waiter
                                 and the lower priority T2 cannot steal the lock.
                              -> fixup_pi_state_owner() sees newowner == NULL -> BUG_ON()
    
    The comment states that this is invalid and rt_mutex_real_owner() must
    return a non NULL owner when the trylock failed, but in case of a queued
    and woken up waiter rt_mutex_real_owner() == NULL is a valid transient
    state. The higher priority waiter has simply not yet managed to take over
    the rtmutex.
    
    The BUG_ON() is therefore wrong and this is just another retry condition in
    fixup_pi_state_owner().
    
    Drop the locks, so that T3 can make progress, and then try the fixup again.
    
    Gratian provided a great analysis, traces and a reproducer. The analysis is
    to the point, but it confused the hell out of that tglx dude who had to
    page in all the futex horrors again. Condensed version is above.
    
    [ tglx: Wrote comment and changelog ]
    
    Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex")
    Reported-by: Gratian Crisan <gratian.crisan@ni.com>
    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87a6w6x7bb.fsf@ni.com
    Link: https://lore.kernel.org/r/87sg9pkvf7.fsf@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbf0928ae355f9cf45d7e46b5115489ddd5f0cd1
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Fri Oct 30 00:19:05 2020 +0800

    tracing: Fix out of bounds write in get_trace_buf
    
    commit c1acb4ac1a892cf08d27efcb964ad281728b0545 upstream.
    
    The nesting count of trace_printk allows for 4 levels of nesting. The
    nesting counter starts at zero and is incremented before being used to
    retrieve the current context's buffer. But the index to the buffer uses the
    nesting counter after it was incremented, and not its original number,
    which in needs to do.
    
    Link: https://lkml.kernel.org/r/20201029161905.4269-1-hqjagain@gmail.com
    
    Cc: stable@vger.kernel.org
    Fixes: 3d9622c12c887 ("tracing: Add barrier to trace_printk() buffer nesting modification")
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e3df0faba7619b6a39695dc4670a9df3b06e555
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Oct 29 19:35:08 2020 -0400

    ftrace: Handle tracing when switching between context
    
    commit 726b3d3f141fba6f841d715fc4d8a4a84f02c02a upstream.
    
    When an interrupt or NMI comes in and switches the context, there's a delay
    from when the preempt_count() shows the update. As the preempt_count() is
    used to detect recursion having each context have its own bit get set when
    tracing starts, and if that bit is already set, it is considered a recursion
    and the function exits. But if this happens in that section where context
    has changed but preempt_count() has not been updated, this will be
    incorrectly flagged as a recursion.
    
    To handle this case, create another bit call TRANSITION and test it if the
    current context bit is already set. Flag the call as a recursion if the
    TRANSITION bit is already set, and if not, set it and continue. The
    TRANSITION bit will be cleared normally on the return of the function that
    set it, or if the current context bit is clear, set it and clear the
    TRANSITION bit to allow for another transition between the current context
    and an even higher one.
    
    Cc: stable@vger.kernel.org
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab3e3ca5445902c7e0bbac2848e2f885d3e0d8b7
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Oct 29 17:31:45 2020 -0400

    ftrace: Fix recursion check for NMI test
    
    commit ee11b93f95eabdf8198edd4668bf9102e7248270 upstream.
    
    The code that checks recursion will work to only do the recursion check once
    if there's nested checks. The top one will do the check, the other nested
    checks will see recursion was already checked and return zero for its "bit".
    On the return side, nothing will be done if the "bit" is zero.
    
    The problem is that zero is returned for the "good" bit when in NMI context.
    This will set the bit for NMIs making it look like *all* NMI tracing is
    recursing, and prevent tracing of anything in NMI context!
    
    The simple fix is to return "bit + 1" and subtract that bit on the end to
    get the real bit.
    
    Cc: stable@vger.kernel.org
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93372bf8418d2da6b2c607da9d62deff7dfebd3a
Author: Alexander Aring <aahringo@redhat.com>
Date:   Mon Oct 26 10:52:29 2020 -0400

    gfs2: Wake up when sd_glock_disposal becomes zero
    
    commit da7d554f7c62d0c17c1ac3cc2586473c2d99f0bd upstream.
    
    Commit fc0e38dae645 ("GFS2: Fix glock deallocation race") fixed a
    sd_glock_disposal accounting bug by adding a missing atomic_dec
    statement, but it failed to wake up sd_glock_wait when that decrement
    causes sd_glock_disposal to reach zero.  As a consequence,
    gfs2_gl_hash_clear can now run into a 10-minute timeout instead of
    being woken up.  Add the missing wakeup.
    
    Fixes: fc0e38dae645 ("GFS2: Fix glock deallocation race")
    Cc: stable@vger.kernel.org # v2.6.39+
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9f46d6c621665eedf3197dc83c0600f8b90c965
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Sun Nov 1 17:08:00 2020 -0800

    mm: always have io_remap_pfn_range() set pgprot_decrypted()
    
    commit f8f6ae5d077a9bdaf5cbf2ac960a5d1a04b47482 upstream.
    
    The purpose of io_remap_pfn_range() is to map IO memory, such as a
    memory mapped IO exposed through a PCI BAR.  IO devices do not
    understand encryption, so this memory must always be decrypted.
    Automatically call pgprot_decrypted() as part of the generic
    implementation.
    
    This fixes a bug where enabling AMD SME causes subsystems, such as RDMA,
    using io_remap_pfn_range() to expose BAR pages to user space to fail.
    The CPU will encrypt access to those BAR pages instead of passing
    unencrypted IO directly to the device.
    
    Places not mapping IO should use remap_pfn_range().
    
    Fixes: aca20d546214 ("x86/mm: Add support to make use of Secure Memory Encryption")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "Dave Young" <dyoung@redhat.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Larry Woodman <lwoodman@redhat.com>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Toshimitsu Kani <toshi.kani@hpe.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/0-v1-025d64bdf6c4+e-amd_sme_fix_jgg@nvidia.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72ae987f4ec92e2f2161ecb2050b59eb2c430af
Author: Zqiang <qiang.zhang@windriver.com>
Date:   Sun Nov 1 17:07:53 2020 -0800

    kthread_worker: prevent queuing delayed work from timer_fn when it is being canceled
    
    commit 6993d0fdbee0eb38bfac350aa016f65ad11ed3b1 upstream.
    
    There is a small race window when a delayed work is being canceled and
    the work still might be queued from the timer_fn:
    
            CPU0                                            CPU1
    kthread_cancel_delayed_work_sync()
       __kthread_cancel_work_sync()
         __kthread_cancel_work()
            work->canceling++;
                                                  kthread_delayed_work_timer_fn()
                                                       kthread_insert_work();
    
    BUG: kthread_insert_work() should not get called when work->canceling is
    set.
    
    Signed-off-by: Zqiang <qiang.zhang@windriver.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20201014083030.16895-1-qiang.zhang@windriver.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc64568652a2808ad0418583eea8f3ef19e8f5f1
Author: Vasily Gorbik <gor@linux.ibm.com>
Date:   Sun Nov 1 17:07:47 2020 -0800

    lib/crc32test: remove extra local_irq_disable/enable
    
    commit aa4e460f0976351fddd2f5ac6e08b74320c277a1 upstream.
    
    Commit 4d004099a668 ("lockdep: Fix lockdep recursion") uncovered the
    following issue in lib/crc32test reported on s390:
    
      BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
      caller is lockdep_hardirqs_on_prepare+0x48/0x270
      CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.9.0-next-20201015-15164-g03d992bd2de6 #19
      Hardware name: IBM 3906 M04 704 (LPAR)
      Call Trace:
        lockdep_hardirqs_on_prepare+0x48/0x270
        trace_hardirqs_on+0x9c/0x1b8
        crc32_test.isra.0+0x170/0x1c0
        crc32test_init+0x1c/0x40
        do_one_initcall+0x40/0x130
        do_initcalls+0x126/0x150
        kernel_init_freeable+0x1f6/0x230
        kernel_init+0x22/0x150
        ret_from_fork+0x24/0x2c
      no locks held by swapper/0/1.
    
    Remove extra local_irq_disable/local_irq_enable helpers calls.
    
    Fixes: 5fb7f87408f1 ("lib: add module support to crc32 tests")
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lkml.kernel.org/r/patch.git-4369da00c06e.your-ad-here.call-01602859837-ext-1679@work.hours
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f8faaaa2dccea71910d723a0602898122f0d639
Author: Geoffrey D. Bennett <g@b4.vu>
Date:   Wed Nov 4 22:27:17 2020 +1030

    ALSA: usb-audio: Add implicit feedback quirk for Qu-16
    
    commit 0938ecae432e7ac8b01080c35dd81d50a1e43033 upstream.
    
    This patch fixes audio distortion on playback for the Allen&Heath
    Qu-16.
    
    Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201104115717.GA19046@b4.vu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7267a7564b56cac62fc2d5d6406e5c925b96a24
Author: Lee Jones <lee.jones@linaro.org>
Date:   Mon Nov 2 13:32:42 2020 -0500

    Fonts: Replace discarded const qualifier
    
    commit 9522750c66c689b739e151fcdf895420dc81efc0 upstream.
    
    Commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros for built-in
    fonts") introduced the following error when building rpc_defconfig (only
    this build appears to be affected):
    
     `acorndata_8x8' referenced in section `.text' of arch/arm/boot/compressed/ll_char_wr.o:
        defined in discarded section `.data' of arch/arm/boot/compressed/font.o
     `acorndata_8x8' referenced in section `.data.rel.ro' of arch/arm/boot/compressed/font.o:
        defined in discarded section `.data' of arch/arm/boot/compressed/font.o
     make[3]: *** [/scratch/linux/arch/arm/boot/compressed/Makefile:191: arch/arm/boot/compressed/vmlinux] Error 1
     make[2]: *** [/scratch/linux/arch/arm/boot/Makefile:61: arch/arm/boot/compressed/vmlinux] Error 2
     make[1]: *** [/scratch/linux/arch/arm/Makefile:317: zImage] Error 2
    
    The .data section is discarded at link time.  Reinstating acorndata_8x8 as
    const ensures it is still available after linking.  Do the same for the
    other 12 built-in fonts as well, for consistency purposes.
    
    Cc: <stable@vger.kernel.org>
    Cc: Russell King <linux@armlinux.org.uk>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts")
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Co-developed-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201102183242.2031659-1-yepeilin.cs@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9674ade91809bfa04c8473a9269e588c389d26b8
Author: Martyna Szapar <martyna.szapar@intel.com>
Date:   Thu Apr 18 13:31:53 2019 -0700

    i40e: Memory leak in i40e_config_iwarp_qvlist
    
    commit 0b63644602cfcbac849f7ea49272a39e90fa95eb upstream.
    
    Added freeing the old allocation of vf->qvlist_info in function
    i40e_config_iwarp_qvlist before overwriting it with
    the new allocation.
    
    Signed-off-by: Martyna Szapar <martyna.szapar@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 571c603adf23a270c6308f9c81abbbca2ebb62de
Author: Martyna Szapar <martyna.szapar@intel.com>
Date:   Mon Apr 15 14:43:07 2019 -0700

    i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c
    
    commit 24474f2709af6729b9b1da1c5e160ab62e25e3a4 upstream.
    
    Fixed possible memory leak in i40e_vc_add_cloud_filter function:
    cfilter is being allocated and in some error conditions
    the function returns without freeing the memory.
    
    Fix of integer truncation from u16 (type of queue_id value) to u8
    when calling i40e_vc_isvalid_queue_id function.
    
    Signed-off-by: Martyna Szapar <martyna.szapar@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    [bwh: Backported to 4.14: i40e_vc_add_cloud_filter() does not exist
     but the integer truncation is still possible]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9900bf4d433be6a2ed8c158779137c7a4742ab67
Author: Grzegorz Siwik <grzegorz.siwik@intel.com>
Date:   Fri Mar 29 15:08:37 2019 -0700

    i40e: Wrong truncation from u16 to u8
    
    commit c004804dceee9ca384d97d9857ea2e2795c2651d upstream.
    
    In this patch fixed wrong truncation method from u16 to u8 during
    validation.
    
    It was changed by changing u8 to u32 parameter in method declaration
    and arguments were changed to u32.
    
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 978c31f09d59cdd52cadc462f12862376e72f618
Author: Sergey Nemov <sergey.nemov@intel.com>
Date:   Fri Mar 29 15:08:36 2019 -0700

    i40e: add num_vectors checker in iwarp handler
    
    commit 7015ca3df965378bcef072cca9cd63ed098665b5 upstream.
    
    Field num_vectors from struct virtchnl_iwarp_qvlist_info should not be
    larger than num_msix_vectors_vf in the hw struct.  The iwarp uses the
    same set of vectors as the LAN VF driver.
    
    Signed-off-by: Sergey Nemov <sergey.nemov@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09f34ad8629919192e429461f0145ddda65fada2
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Aug 6 23:37:01 2017 +0200

    i40e: Fix a potential NULL pointer dereference
    
    commit 54902349ee95045b67e2f0c39b75f5418540064b upstream.
    
    If 'kzalloc()' fails, a NULL pointer will be dereferenced.
    Return an error code (-ENOMEM) instead.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8268f88785ca9476c68da06d1f93c3d0d9747d28
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Fri Jun 19 20:47:28 2020 +0000

    blktrace: fix debugfs use after free
    
    commit bad8e64fb19d3a0de5e564d9a7271c31bd684369 upstream.
    
    On commit 6ac93117ab00 ("blktrace: use existing disk debugfs directory")
    merged on v4.12 Omar fixed the original blktrace code for request-based
    drivers (multiqueue). This however left in place a possible crash, if you
    happen to abuse blktrace while racing to remove / add a device.
    
    We used to use asynchronous removal of the request_queue, and with that
    the issue was easier to reproduce. Now that we have reverted to
    synchronous removal of the request_queue, the issue is still possible to
    reproduce, its however just a bit more difficult.
    
    We essentially run two instances of break-blktrace which add/remove
    a loop device, and setup a blktrace and just never tear the blktrace
    down. We do this twice in parallel. This is easily reproduced with the
    script run_0004.sh from break-blktrace [0].
    
    We can end up with two types of panics each reflecting where we
    race, one a failed blktrace setup:
    
    [  252.426751] debugfs: Directory 'loop0' with parent 'block' already present!
    [  252.432265] BUG: kernel NULL pointer dereference, address: 00000000000000a0
    [  252.436592] #PF: supervisor write access in kernel mode
    [  252.439822] #PF: error_code(0x0002) - not-present page
    [  252.442967] PGD 0 P4D 0
    [  252.444656] Oops: 0002 [#1] SMP NOPTI
    [  252.446972] CPU: 10 PID: 1153 Comm: break-blktrace Tainted: G            E     5.7.0-rc2-next-20200420+ #164
    [  252.452673] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
    [  252.456343] RIP: 0010:down_write+0x15/0x40
    [  252.458146] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
                   cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
                   00 00 <f0> 48 0f b1 55 00 75 0f 48 8b 04 25 c0 8b 01 00 48 89
                   45 08 5d
    [  252.463638] RSP: 0018:ffffa626415abcc8 EFLAGS: 00010246
    [  252.464950] RAX: 0000000000000000 RBX: ffff958c25f0f5c0 RCX: ffffff8100000000
    [  252.466727] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0
    [  252.468482] RBP: 00000000000000a0 R08: 0000000000000000 R09: 0000000000000001
    [  252.470014] R10: 0000000000000000 R11: ffff958d1f9227ff R12: 0000000000000000
    [  252.471473] R13: ffff958c25ea5380 R14: ffffffff8cce15f1 R15: 00000000000000a0
    [  252.473346] FS:  00007f2e69dee540(0000) GS:ffff958c2fc80000(0000) knlGS:0000000000000000
    [  252.475225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  252.476267] CR2: 00000000000000a0 CR3: 0000000427d10004 CR4: 0000000000360ee0
    [  252.477526] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  252.478776] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  252.479866] Call Trace:
    [  252.480322]  simple_recursive_removal+0x4e/0x2e0
    [  252.481078]  ? debugfs_remove+0x60/0x60
    [  252.481725]  ? relay_destroy_buf+0x77/0xb0
    [  252.482662]  debugfs_remove+0x40/0x60
    [  252.483518]  blk_remove_buf_file_callback+0x5/0x10
    [  252.484328]  relay_close_buf+0x2e/0x60
    [  252.484930]  relay_open+0x1ce/0x2c0
    [  252.485520]  do_blk_trace_setup+0x14f/0x2b0
    [  252.486187]  __blk_trace_setup+0x54/0xb0
    [  252.486803]  blk_trace_ioctl+0x90/0x140
    [  252.487423]  ? do_sys_openat2+0x1ab/0x2d0
    [  252.488053]  blkdev_ioctl+0x4d/0x260
    [  252.488636]  block_ioctl+0x39/0x40
    [  252.489139]  ksys_ioctl+0x87/0xc0
    [  252.489675]  __x64_sys_ioctl+0x16/0x20
    [  252.490380]  do_syscall_64+0x52/0x180
    [  252.491032]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    And the other on the device removal:
    
    [  128.528940] debugfs: Directory 'loop0' with parent 'block' already present!
    [  128.615325] BUG: kernel NULL pointer dereference, address: 00000000000000a0
    [  128.619537] #PF: supervisor write access in kernel mode
    [  128.622700] #PF: error_code(0x0002) - not-present page
    [  128.625842] PGD 0 P4D 0
    [  128.627585] Oops: 0002 [#1] SMP NOPTI
    [  128.629871] CPU: 12 PID: 544 Comm: break-blktrace Tainted: G            E     5.7.0-rc2-next-20200420+ #164
    [  128.635595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
    [  128.640471] RIP: 0010:down_write+0x15/0x40
    [  128.643041] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
                   cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
                   00 00 <f0> 48 0f b1 55 00 75 0f 65 48 8b 04 25 c0 8b 01 00 48 89
                   45 08 5d
    [  128.650180] RSP: 0018:ffffa9c3c05ebd78 EFLAGS: 00010246
    [  128.651820] RAX: 0000000000000000 RBX: ffff8ae9a6370240 RCX: ffffff8100000000
    [  128.653942] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0
    [  128.655720] RBP: 00000000000000a0 R08: 0000000000000002 R09: ffff8ae9afd2d3d0
    [  128.657400] R10: 0000000000000056 R11: 0000000000000000 R12: 0000000000000000
    [  128.659099] R13: 0000000000000000 R14: 0000000000000003 R15: 00000000000000a0
    [  128.660500] FS:  00007febfd995540(0000) GS:ffff8ae9afd00000(0000) knlGS:0000000000000000
    [  128.662204] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  128.663426] CR2: 00000000000000a0 CR3: 0000000420042003 CR4: 0000000000360ee0
    [  128.664776] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  128.666022] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  128.667282] Call Trace:
    [  128.667801]  simple_recursive_removal+0x4e/0x2e0
    [  128.668663]  ? debugfs_remove+0x60/0x60
    [  128.669368]  debugfs_remove+0x40/0x60
    [  128.669985]  blk_trace_free+0xd/0x50
    [  128.670593]  __blk_trace_remove+0x27/0x40
    [  128.671274]  blk_trace_shutdown+0x30/0x40
    [  128.671935]  blk_release_queue+0x95/0xf0
    [  128.672589]  kobject_put+0xa5/0x1b0
    [  128.673188]  disk_release+0xa2/0xc0
    [  128.673786]  device_release+0x28/0x80
    [  128.674376]  kobject_put+0xa5/0x1b0
    [  128.674915]  loop_remove+0x39/0x50 [loop]
    [  128.675511]  loop_control_ioctl+0x113/0x130 [loop]
    [  128.676199]  ksys_ioctl+0x87/0xc0
    [  128.676708]  __x64_sys_ioctl+0x16/0x20
    [  128.677274]  do_syscall_64+0x52/0x180
    [  128.677823]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    The common theme here is:
    
    debugfs: Directory 'loop0' with parent 'block' already present
    
    This crash happens because of how blktrace uses the debugfs directory
    where it places its files. Upon init we always create the same directory
    which would be needed by blktrace but we only do this for make_request
    drivers (multiqueue) block drivers. When you race a removal of these
    devices with a blktrace setup you end up in a situation where the
    make_request recursive debugfs removal will sweep away the blktrace
    files and then later blktrace will also try to remove individual
    dentries which are already NULL. The inverse is also possible and hence
    the two types of use after frees.
    
    We don't create the block debugfs directory on init for these types of
    block devices:
    
      * request-based block driver block devices
      * every possible partition
      * scsi-generic
    
    And so, this race should in theory only be possible with make_request
    drivers.
    
    We can fix the UAF by simply re-using the debugfs directory for
    make_request drivers (multiqueue) and only creating the ephemeral
    directory for the other type of block devices. The new clarifications
    on relying on the q->blk_trace_mutex *and* also checking for q->blk_trace
    *prior* to processing a blktrace ensures the debugfs directories are
    only created if no possible directory name clashes are possible.
    
    This goes tested with:
    
      o nvme partitions
      o ISCSI with tgt, and blktracing against scsi-generic with:
        o block
        o tape
        o cdrom
        o media changer
      o blktests
    
    This patch is part of the work which disputes the severity of
    CVE-2019-19770 which shows this issue is not a core debugfs issue, but
    a misuse of debugfs within blktace.
    
    Fixes: 6ac93117ab00 ("blktrace: use existing disk debugfs directory")
    Reported-by: syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Omar Sandoval <osandov@fb.com>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Nicolai Stange <nstange@suse.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: yu kuai <yukuai3@huawei.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 4.14: open-code queue_is_mq()]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 595290ccd13a8af9463a02b447860ca12b4e3254
Author: Liu Bo <bo.liu@linux.alibaba.com>
Date:   Fri Jun 29 09:56:08 2018 +0800

    Blktrace: bail out early if block debugfs is not configured
    
    commit e1a413245a564683697a3d02ec197b72cf009b89 upstream.
    
    Since @blk_debugfs_root couldn't be configured dynamically, we can
    save a few memory allocation if it's not there.
    
    Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Cherry-picked for 4.14 to ease backporting a later fix]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4592235990566fc74d364f54f6e77ee5d4b443f9
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat Oct 31 11:10:53 2020 +0800

    sfp: Fix error handing in sfp_probe()
    
    [ Upstream commit 9621618130bf7e83635367c13b9a6ee53935bb37 ]
    
    gpiod_to_irq() never return 0, but returns negative in
    case of error, check it and set gpio_irq to 0.
    
    Fixes: 73970055450e ("sfp: add SFP module support")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20201031031053.25264-1-yuehaibing@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1c072c2860d2126ab30839c0500f7a088a7319b
Author: Petr Malat <oss@malat.biz>
Date:   Fri Oct 30 14:26:33 2020 +0100

    sctp: Fix COMM_LOST/CANT_STR_ASSOC err reporting on big-endian platforms
    
    [ Upstream commit b6df8c81412190fbd5eaa3cec7f642142d9c16cd ]
    
    Commit 978aa0474115 ("sctp: fix some type cast warnings introduced since
    very beginning")' broke err reading from sctp_arg, because it reads the
    value as 32-bit integer, although the value is stored as 16-bit integer.
    Later this value is passed to the userspace in 16-bit variable, thus the
    user always gets 0 on big-endian platforms. Fix it by reading the __u16
    field of sctp_arg union, as reading err field would produce a sparse
    warning.
    
    Fixes: 978aa0474115 ("sctp: fix some type cast warnings introduced since very beginning")
    Signed-off-by: Petr Malat <oss@malat.biz>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Link: https://lore.kernel.org/r/20201030132633.7045-1-oss@malat.biz
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1971ba6386d5ac078ab37f05e801a92ff6161c4f
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Mon Nov 2 12:01:08 2020 +0100

    net: usb: qmi_wwan: add Telit LE910Cx 0x1230 composition
    
    [ Upstream commit 5fd8477ed8ca77e64b93d44a6dae4aa70c191396 ]
    
    Add support for Telit LE910Cx 0x1230 composition:
    
    0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20201102110108.17244-1-dnlplm@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6f82a26ba220528796ea91de141ee4722e7c5b7
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Tue Oct 20 20:36:05 2020 +0300

    gianfar: Account for Tx PTP timestamp in the skb headroom
    
    [ Upstream commit d6a076d68c6b5d6a5800f3990a513facb7016dea ]
    
    When PTP timestamping is enabled on Tx, the controller
    inserts the Tx timestamp at the beginning of the frame
    buffer, between SFD and the L2 frame header. This means
    that the skb provided by the stack is required to have
    enough headroom otherwise a new skb needs to be created
    by the driver to accommodate the timestamp inserted by h/w.
    Up until now the driver was relying on the second option,
    using skb_realloc_headroom() to create a new skb to accommodate
    PTP frames. Turns out that this method is not reliable, as
    reallocation of skbs for PTP frames along with the required
    overhead (skb_set_owner_w, consume_skb) is causing random
    crashes in subsequent skb_*() calls, when multiple concurrent
    TCP streams are run at the same time on the same device
    (as seen in James' report).
    Note that these crashes don't occur with a single TCP stream,
    nor with multiple concurrent UDP streams, but only when multiple
    TCP streams are run concurrently with the PTP packet flow
    (doing skb reallocation).
    This patch enforces the first method, by requesting enough
    headroom from the stack to accommodate PTP frames, and so avoiding
    skb_realloc_headroom() & co, and the crashes no longer occur.
    There's no reason not to set needed_headroom to a large enough
    value to accommodate PTP frames, so in this regard this patch
    is a fix.
    
    Reported-by: James Jurack <james.jurack@ametek.com>
    Fixes: bee9e58c9e98 ("gianfar:don't add FCB length to hard_header_len")
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20201020173605.1173-1-claudiu.manoil@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1e4849a7987353e50da07327b38884caed24f44
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Thu Oct 29 10:10:56 2020 +0200

    gianfar: Replace skb_realloc_headroom with skb_cow_head for PTP
    
    [ Upstream commit d145c9031325fed963a887851d9fa42516efd52b ]
    
    When PTP timestamping is enabled on Tx, the controller
    inserts the Tx timestamp at the beginning of the frame
    buffer, between SFD and the L2 frame header.  This means
    that the skb provided by the stack is required to have
    enough headroom otherwise a new skb needs to be created
    by the driver to accommodate the timestamp inserted by h/w.
    Up until now the driver was relying on skb_realloc_headroom()
    to create new skbs to accommodate PTP frames.  Turns out that
    this method is not reliable in this context at least, as
    skb_realloc_headroom() for PTP frames can cause random crashes,
    mostly in subsequent skb_*() calls, when multiple concurrent
    TCP streams are run at the same time with the PTP flow
    on the same device (as seen in James' report).  I also noticed
    that when the system is loaded by sending multiple TCP streams,
    the driver receives cloned skbs in large numbers.
    skb_cow_head() instead proves to be stable in this scenario,
    and not only handles cloned skbs too but it's also more efficient
    and widely used in other drivers.
    The commit introducing skb_realloc_headroom in the driver
    goes back to 2009, commit 93c1285c5d92
    ("gianfar: reallocate skb when headroom is not enough for fcb").
    For practical purposes I'm referencing a newer commit (from 2012)
    that brings the code to its current structure (and fixes the PTP
    case).
    
    Fixes: 9c4886e5e63b ("gianfar: Fix invalid TX frames returned on error queue when time stamping")
    Reported-by: James Jurack <james.jurack@ametek.com>
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20201029081057.8506-1-claudiu.manoil@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ac95d9564041a4f469e5c71884f4d7821ce68b2
Author: Hoang Huu Le <hoang.h.le@dektech.com.au>
Date:   Thu Aug 27 09:56:51 2020 +0700

    tipc: fix use-after-free in tipc_bcast_get_mode
    
    commit fdeba99b1e58ecd18c2940c453e19e4ef20ff591 upstream.
    
    Syzbot has reported those issues as:
    
    ==================================================================
    BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
    Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850
    
    CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events tipc_net_finalize_work
    
    Thread 1's call trace:
    [...]
      kfree+0x103/0x2c0 mm/slab.c:3757 <- bcbase releasing
      tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721
      tipc_exit_net+0x24/0x270 net/tipc/core.c:112
    [...]
    
    Thread 2's call trace:
    [...]
      tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 <- bcbase
    has already been freed by Thread 1
    
      tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744
      tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752
      tipc_net_finalize net/tipc/net.c:141 [inline]
      tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131
      tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150
    [...]
    
    ==================================================================
    BUG: KASAN: use-after-free in tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344
    Read of size 8 at addr ffff888052ab2000 by task kworker/0:13/30628
    CPU: 0 PID: 30628 Comm: kworker/0:13 Not tainted 5.8.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events tipc_net_finalize_work
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1f0/0x31e lib/dump_stack.c:118
     print_address_description+0x66/0x5a0 mm/kasan/report.c:383
     __kasan_report mm/kasan/report.c:513 [inline]
     kasan_report+0x132/0x1d0 mm/kasan/report.c:530
     tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344
     tipc_net_finalize+0x85/0xe0 net/tipc/net.c:138
     tipc_net_finalize_work+0x50/0x70 net/tipc/net.c:150
     process_one_work+0x789/0xfc0 kernel/workqueue.c:2269
     worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415
     kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
    [...]
    Freed by task 14058:
     save_stack mm/kasan/common.c:48 [inline]
     set_track mm/kasan/common.c:56 [inline]
     kasan_set_free_info mm/kasan/common.c:316 [inline]
     __kasan_slab_free+0x114/0x170 mm/kasan/common.c:455
     __cache_free mm/slab.c:3426 [inline]
     kfree+0x10a/0x220 mm/slab.c:3757
     tipc_exit_net+0x29/0x50 net/tipc/core.c:113
     ops_exit_list net/core/net_namespace.c:186 [inline]
     cleanup_net+0x708/0xba0 net/core/net_namespace.c:603
     process_one_work+0x789/0xfc0 kernel/workqueue.c:2269
     worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415
     kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
    
    Fix it by calling flush_scheduled_work() to make sure the
    tipc_net_finalize_work() stopped before releasing bcbase object.
    
    Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com
    Reported-by: syzbot+e9cc557752ab126c1b99@syzkaller.appspotmail.com
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 776bce2df0bdcbe83e1c85398646745a50f1d8f4
Author: Juergen Gross <jgross@suse.com>
Date:   Wed Sep 30 11:16:14 2020 +0200

    xen/events: don't use chip_data for legacy IRQs
    
    commit 0891fb39ba67bd7ae023ea0d367297ffff010781 upstream.
    
    Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.")
    Xen is using the chip_data pointer for storing IRQ specific data. When
    running as a HVM domain this can result in problems for legacy IRQs, as
    those might use chip_data for their own purposes.
    
    Use a local array for this purpose in case of legacy IRQs, avoiding the
    double use.
    
    Cc: stable@vger.kernel.org
    Fixes: c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Tested-by: Stefan Bader <stefan.bader@canonical.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: https://lore.kernel.org/r/20200930091614.13660-1-jgross@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    [bwh: Backported to 4.9: adjust context]
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9be7583938fdc279ed1f826d90857155f2cd45b6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 16 10:00:58 2020 +0100

    drm/i915: Break up error capture compression loops with cond_resched()
    
    commit 7d5553147613b50149238ac1385c60e5c7cacb34 upstream.
    
    As the error capture will compress user buffers as directed to by the
    user, it can take an arbitrary amount of time and space. Break up the
    compression loops with a call to cond_resched(), that will allow other
    processes to schedule (avoiding the soft lockups) and also serve as a
    warning should we try to make this loop atomic in the future.
    
    Testcase: igt/gem_exec_capture/many-*
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200916090059.3189-2-chris@chris-wilson.co.uk
    (cherry picked from commit 293f43c80c0027ff9299036c24218ac705ce584e)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>