commit d72237c1e00f85e5df1c040280d50561c8a28329
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed May 20 08:11:57 2020 +0200

    Linux 4.4.224

commit fbc09f1ef04823dd84390faf308d2b49d0a0545b
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Dec 9 09:34:57 2019 -0800

    scsi: iscsi: Fix a potential deadlock in the timeout handler
    
    commit 5480e299b5ae57956af01d4839c9fc88a465eeab upstream.
    
    Some time ago the block layer was modified such that timeout handlers are
    called from thread context instead of interrupt context. Make it safe to
    run the iSCSI timeout handler in thread context. This patch fixes the
    following lockdep complaint:
    
    ================================
    WARNING: inconsistent lock state
    5.5.1-dbg+ #11 Not tainted
    --------------------------------
    inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    kworker/7:1H/206 [HC0[0]:SC0[0]:HE1:SE1] takes:
    ffff88802d9827e8 (&(&session->frwd_lock)->rlock){+.?.}, at: iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
    {IN-SOFTIRQ-W} state was registered at:
      lock_acquire+0x106/0x240
      _raw_spin_lock+0x38/0x50
      iscsi_check_transport_timeouts+0x3e/0x210 [libiscsi]
      call_timer_fn+0x132/0x470
      __run_timers.part.0+0x39f/0x5b0
      run_timer_softirq+0x63/0xc0
      __do_softirq+0x12d/0x5fd
      irq_exit+0xb3/0x110
      smp_apic_timer_interrupt+0x131/0x3d0
      apic_timer_interrupt+0xf/0x20
      default_idle+0x31/0x230
      arch_cpu_idle+0x13/0x20
      default_idle_call+0x53/0x60
      do_idle+0x38a/0x3f0
      cpu_startup_entry+0x24/0x30
      start_secondary+0x222/0x290
      secondary_startup_64+0xa4/0xb0
    irq event stamp: 1383705
    hardirqs last  enabled at (1383705): [<ffffffff81aace5c>] _raw_spin_unlock_irq+0x2c/0x50
    hardirqs last disabled at (1383704): [<ffffffff81aacb98>] _raw_spin_lock_irq+0x18/0x50
    softirqs last  enabled at (1383690): [<ffffffffa0e2efea>] iscsi_queuecommand+0x76a/0xa20 [libiscsi]
    softirqs last disabled at (1383682): [<ffffffffa0e2e998>] iscsi_queuecommand+0x118/0xa20 [libiscsi]
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&session->frwd_lock)->rlock);
      <Interrupt>
        lock(&(&session->frwd_lock)->rlock);
    
     *** DEADLOCK ***
    
    2 locks held by kworker/7:1H/206:
     #0: ffff8880d57bf928 ((wq_completion)kblockd){+.+.}, at: process_one_work+0x472/0xab0
     #1: ffff88802b9c7de8 ((work_completion)(&q->timeout_work)){+.+.}, at: process_one_work+0x476/0xab0
    
    stack backtrace:
    CPU: 7 PID: 206 Comm: kworker/7:1H Not tainted 5.5.1-dbg+ #11
    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    Workqueue: kblockd blk_mq_timeout_work
    Call Trace:
     dump_stack+0xa5/0xe6
     print_usage_bug.cold+0x232/0x23b
     mark_lock+0x8dc/0xa70
     __lock_acquire+0xcea/0x2af0
     lock_acquire+0x106/0x240
     _raw_spin_lock+0x38/0x50
     iscsi_eh_cmd_timed_out+0xa6/0x6d0 [libiscsi]
     scsi_times_out+0xf4/0x440 [scsi_mod]
     scsi_timeout+0x1d/0x20 [scsi_mod]
     blk_mq_check_expired+0x365/0x3a0
     bt_iter+0xd6/0xf0
     blk_mq_queue_tag_busy_iter+0x3de/0x650
     blk_mq_timeout_work+0x1af/0x380
     process_one_work+0x56d/0xab0
     worker_thread+0x7a/0x5d0
     kthread+0x1bc/0x210
     ret_from_fork+0x24/0x30
    
    Fixes: 287922eb0b18 ("block: defer timeouts to a workqueue")
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Keith Busch <keith.busch@intel.com>
    Cc: Lee Duncan <lduncan@suse.com>
    Cc: Chris Leech <cleech@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20191209173457.187370-1-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: Henri Rosten <henri.rosten@unikie.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8291f17dc2fe77095c57ed6e058ee07146300fbd
Author: Sergei Trofimovich <slyfox@gentoo.org>
Date:   Tue Mar 17 00:07:18 2020 +0000

    Makefile: disallow data races on gcc-10 as well
    
    commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream.
    
    gcc-10 will rename --param=allow-store-data-races=0
    to -fno-allow-store-data-races.
    
    The flag change happened at https://gcc.gnu.org/PR92046.
    
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Thomas Backlund <tmb@mageia.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4143cea5997307539e2359f2c552f61f17ce6091
Author: Jim Mattson <jmattson@google.com>
Date:   Mon May 11 15:56:16 2020 -0700

    KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
    
    commit c4e0e4ab4cf3ec2b3f0b628ead108d677644ebd9 upstream.
    
    Bank_num is a one-based count of banks, not a zero-based index. It
    overflows the allocated space only when strictly greater than
    KVM_MAX_MCE_BANKS.
    
    Fixes: a9e38c3e01ad ("KVM: x86: Catch potential overrun in MCE setup")
    Signed-off-by: Jue Wang <juew@google.com>
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Peter Shier <pshier@google.com>
    Message-Id: <20200511225616.19557-1-jmattson@google.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07fbc97743b9db0fac694adcecb22ce57f66e79c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri May 8 11:59:18 2020 +0200

    ARM: dts: r8a7740: Add missing extal2 to CPG node
    
    commit e47cb97f153193d4b41ca8d48127da14513d54c7 upstream.
    
    The Clock Pulse Generator (CPG) device node lacks the extal2 clock.
    This may lead to a failure registering the "r" clock, or to a wrong
    parent for the "usb24s" clock, depending on MD_CK2 pin configuration and
    boot loader CPG_USBCKCR register configuration.
    
    This went unnoticed, as this does not affect the single upstream board
    configuration, which relies on the first clock input only.
    
    Fixes: d9ffd583bf345e2e ("ARM: shmobile: r8a7740: add SoC clocks to DTS")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
    Link: https://lore.kernel.org/r/20200508095918.6061-1-geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 011449cfc25403baa64d59f03a61bb4f4f7d0340
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Sun May 3 23:24:46 2020 +0800

    Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
    
    commit f41224efcf8aafe80ea47ac870c5e32f3209ffc8 upstream.
    
    This reverts commit 3b36b13d5e69d6f51ff1c55d1b404a74646c9757.
    
    Enable power save node breaks some systems with ACL225. Revert the patch
    and use a platform specific quirk for the original issue isntead.
    
    Fixes: 3b36b13d5e69 ("ALSA: hda/realtek: Fix pop noise on ALC225")
    BugLink: https://bugs.launchpad.net/bugs/1875916
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Link: https://lore.kernel.org/r/20200503152449.22761-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dea7c8ebf7303544b04e28ffd8ec120b26550208
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Thu May 7 05:13:32 2020 +0000

    usb: gadget: legacy: fix error return code in cdc_bind()
    
    commit e8f7f9e3499a6d96f7f63a4818dc7d0f45a7783b upstream.
    
    If 'usb_otg_descriptor_alloc()' fails, we must return a
    negative error code -ENOMEM, not 0.
    
    Fixes: ab6796ae9833 ("usb: gadget: cdc2: allocate and init otg descriptor by otg capabilities")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82fc349bfd8bfea57ad4174cac6c8851a0a05c13
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Thu May 7 05:13:23 2020 +0000

    usb: gadget: legacy: fix error return code in gncm_bind()
    
    commit e27d4b30b71c66986196d8a1eb93cba9f602904a upstream.
    
    If 'usb_otg_descriptor_alloc()' fails, we must return a
    negative error code -ENOMEM, not 0.
    
    Fixes: 1156e91dd7cc ("usb: gadget: ncm: allocate and init otg descriptor by otg capabilities")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f0919d6788f841b3333959080ac1a344ec146b1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun May 3 12:47:07 2020 +0200

    usb: gadget: audio: Fix a missing error return value in audio_bind()
    
    commit 19b94c1f9c9a16d41a8de3ccbdb8536cf1aecdbf upstream.
    
    If 'usb_otg_descriptor_alloc()' fails, we must return an error code, not 0.
    
    Fixes: 56023ce0fd70 ("usb: gadget: audio: allocate and init otg descriptor by otg capabilities")
    Reviewed-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dfdd767cffb4f3437cea6f300bc11e1be104fe9
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Apr 27 20:04:23 2020 +0200

    usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()'
    
    commit ccaef7e6e354fb65758eaddd3eae8065a8b3e295 upstream.
    
    'dev' is allocated in 'net2272_probe_init()'. It must be freed in the error
    handling path, as already done in the remove function (i.e.
    'net2272_plat_remove()')
    
    Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84cd70984ed2e3a94dfc4325d9237b90ac4dae3a
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sat May 16 16:29:20 2020 -0500

    exec: Move would_dump into flush_old_exec
    
    commit f87d1c9559164294040e58f5e3b74a162bf7c6e8 upstream.
    
    I goofed when I added mm->user_ns support to would_dump.  I missed the
    fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and
    binfmt_script bprm->file is reassigned.  Which made the move of
    would_dump from setup_new_exec to __do_execve_file before exec_binprm
    incorrect as it can result in would_dump running on the script instead
    of the interpreter of the script.
    
    The net result is that the code stopped making unreadable interpreters
    undumpable.  Which allows them to be ptraced and written to disk
    without special permissions.  Oops.
    
    The move was necessary because the call in set_new_exec was after
    bprm->mm was no longer valid.
    
    To correct this mistake move the misplaced would_dump from
    __do_execve_file into flos_old_exec, before exec_mmap is called.
    
    I tested and confirmed that without this fix I can attach with gdb to
    a script with an unreadable interpreter, and with this fix I can not.
    
    Cc: stable@vger.kernel.org
    Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afa0b39ebe5803abe5a9301700dbede92a3379cd
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Apr 22 18:11:30 2020 +0200

    x86: Fix early boot crash on gcc-10, third try
    
    commit a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e upstream.
    
    ... or the odyssey of trying to disable the stack protector for the
    function which generates the stack canary value.
    
    The whole story started with Sergei reporting a boot crash with a kernel
    built with gcc-10:
    
      Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139
      Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013
      Call Trace:
        dump_stack
        panic
        ? start_secondary
        __stack_chk_fail
        start_secondary
        secondary_startup_64
      -—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary
    
    This happens because gcc-10 tail-call optimizes the last function call
    in start_secondary() - cpu_startup_entry() - and thus emits a stack
    canary check which fails because the canary value changes after the
    boot_init_stack_canary() call.
    
    To fix that, the initial attempt was to mark the one function which
    generates the stack canary with:
    
      __attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused)
    
    however, using the optimize attribute doesn't work cumulatively
    as the attribute does not add to but rather replaces previously
    supplied optimization options - roughly all -fxxx options.
    
    The key one among them being -fno-omit-frame-pointer and thus leading to
    not present frame pointer - frame pointer which the kernel needs.
    
    The next attempt to prevent compilers from tail-call optimizing
    the last function call cpu_startup_entry(), shy of carving out
    start_secondary() into a separate compilation unit and building it with
    -fno-stack-protector, was to add an empty asm("").
    
    This current solution was short and sweet, and reportedly, is supported
    by both compilers but we didn't get very far this time: future (LTO?)
    optimization passes could potentially eliminate this, which leads us
    to the third attempt: having an actual memory barrier there which the
    compiler cannot ignore or move around etc.
    
    That should hold for a long time, but hey we said that about the other
    two solutions too so...
    
    Reported-by: Sergei Trofimovich <slyfox@gentoo.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Tested-by: Kalle Valo <kvalo@codeaurora.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb5809183912b4930bfcd8bada4d9a06bece159b
Author: Fabio Estevam <festevam@gmail.com>
Date:   Fri Mar 27 10:36:24 2020 -0300

    ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
    
    commit 0caf34350a25907515d929a9c77b9b206aac6d1e upstream.
    
    The I2C2 pins are already used and the following errors are seen:
    
    imx27-pinctrl 10015000.iomuxc: pin MX27_PAD_I2C2_SDA already requested by 10012000.i2c; cannot claim for 1001d000.i2c
    imx27-pinctrl 10015000.iomuxc: pin-69 (1001d000.i2c) status -22
    imx27-pinctrl 10015000.iomuxc: could not request pin 69 (MX27_PAD_I2C2_SDA) from group i2c2grp  on device 10015000.iomuxc
    imx-i2c 1001d000.i2c: Error applying setting, reverse things back
    imx-i2c: probe of 1001d000.i2c failed with error -22
    
    Fix it by adding the correct I2C1 IOMUX entries for the pinctrl_i2c1 group.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 61664d0b432a ("ARM: dts: imx27 phyCARD-S pinctrl")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Stefan Riedmueller <s.riedmueller@phytec.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c18a8b0d7b8fdb299bcfab2feb9c0f410580794a
Author: Kyungtae Kim <kt0755@gmail.com>
Date:   Sun May 10 05:43:34 2020 +0000

    USB: gadget: fix illegal array access in binding with UDC
    
    commit 15753588bcd4bbffae1cca33c8ced5722477fe1f upstream.
    
    FuzzUSB (a variant of syzkaller) found an illegal array access
    using an incorrect index while binding a gadget with UDC.
    
    Reference: https://www.spinics.net/lists/linux-usb/msg194331.html
    
    This bug occurs when a size variable used for a buffer
    is misused to access its strcpy-ed buffer.
    Given a buffer along with its size variable (taken from user input),
    from which, a new buffer is created using kstrdup().
    Due to the original buffer containing 0 value in the middle,
    the size of the kstrdup-ed buffer becomes smaller than that of the original.
    So accessing the kstrdup-ed buffer with the same size variable
    triggers memory access violation.
    
    The fix makes sure no zero value in the buffer,
    by comparing the strlen() of the orignal buffer with the size variable,
    so that the access to the kstrdup-ed buffer is safe.
    
    BUG: KASAN: slab-out-of-bounds in gadget_dev_desc_UDC_store+0x1ba/0x200
    drivers/usb/gadget/configfs.c:266
    Read of size 1 at addr ffff88806a55dd7e by task syz-executor.0/17208
    
    CPU: 2 PID: 17208 Comm: syz-executor.0 Not tainted 5.6.8 #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xce/0x128 lib/dump_stack.c:118
     print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
     __kasan_report+0x131/0x1b0 mm/kasan/report.c:506
     kasan_report+0x12/0x20 mm/kasan/common.c:641
     __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132
     gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266
     flush_write_buffer fs/configfs/file.c:251 [inline]
     configfs_write_file+0x2f1/0x4c0 fs/configfs/file.c:283
     __vfs_write+0x85/0x110 fs/read_write.c:494
     vfs_write+0x1cd/0x510 fs/read_write.c:558
     ksys_write+0x18a/0x220 fs/read_write.c:611
     __do_sys_write fs/read_write.c:623 [inline]
     __se_sys_write fs/read_write.c:620 [inline]
     __x64_sys_write+0x73/0xb0 fs/read_write.c:620
     do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Signed-off-by: Kyungtae Kim <kt0755@gmail.com>
    Reported-and-tested-by: Kyungtae Kim <kt0755@gmail.com>
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200510054326.GA19198@pizza01
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41d7b565440dbd3bd70f23469fb600071c574bd5
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 3 15:16:43 2018 +0200

    ALSA: rawmidi: Initialize allocated buffers
    
    commit 5a7b44a8df822e0667fc76ed7130252523993bda upstream.
    
    syzbot reported the uninitialized value exposure in certain situations
    using virmidi loop.  It's likely a very small race at writing and
    reading, and the influence is almost negligible.  But it's safer to
    paper over this just by replacing the existing kvmalloc() with
    kvzalloc().
    
    Reported-by: syzbot+194dffdb8b22fc5d207a@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 718eede1eeb602531e09191d3107eb849bbe64eb
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu May 7 13:44:56 2020 +0200

    ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
    
    commit c1f6e3c818dd734c30f6a7eeebf232ba2cf3181d upstream.
    
    The rawmidi core allows user to resize the runtime buffer via ioctl,
    and this may lead to UAF when performed during concurrent reads or
    writes: the read/write functions unlock the runtime lock temporarily
    during copying form/to user-space, and that's the race window.
    
    This patch fixes the hole by introducing a reference counter for the
    runtime buffer read/write access and returns -EBUSY error when the
    resize is performed concurrently against read/write.
    
    Note that the ref count field is a simple integer instead of
    refcount_t here, since the all contexts accessing the buffer is
    basically protected with a spinlock, hence we need no expensive atomic
    ops.  Also, note that this busy check is needed only against read /
    write functions, and not in receive/transmit callbacks; the race can
    happen only at the spinlock hole mentioned in the above, while the
    whole function is protected for receive / transmit callbacks.
    
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
    Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac1eb6222b6b1da685df4dd1694a92b1403b7f1f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu May 14 18:05:33 2020 +0200

    ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
    
    commit b590b38ca305d6d7902ec7c4f7e273e0069f3bcc upstream.
    
    Lenovo Thinkpad T530 seems to have a sensitive internal mic capture
    that needs to limit the mic boost like a few other Thinkpad models.
    Although we may change the quirk for ALC269_FIXUP_LENOVO_DOCK, this
    hits way too many other laptop models, so let's add a new fixup model
    that limits the internal mic boost on top of the existing quirk and
    apply to only T530.
    
    BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1171293
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200514160533.10337-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8ff52e4bdaabfee050ae4e8c721305a924a8633
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue May 12 14:43:14 2020 +0200

    netlabel: cope with NULL catmap
    
    [ Upstream commit eead1c2ea2509fd754c6da893a94f0e69e83ebe4 ]
    
    The cipso and calipso code can set the MLS_CAT attribute on
    successful parsing, even if the corresponding catmap has
    not been allocated, as per current configuration and external
    input.
    
    Later, selinux code tries to access the catmap if the MLS_CAT flag
    is present via netlbl_catmap_getlong(). That may cause null ptr
    dereference while processing incoming network traffic.
    
    Address the issue setting the MLS_CAT flag only if the catmap is
    really allocated. Additionally let netlbl_catmap_getlong() cope
    with NULL catmap.
    
    Reported-by: Matthew Sheets <matthew.sheets@gd-ms.com>
    Fixes: 4b8feff251da ("netlabel: fix the horribly broken catmap functions")
    Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98ee7d0d6a2b4724a0760cf2a0cb72c38b2aa985
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri May 8 19:28:34 2020 +0200

    net: ipv4: really enforce backoff for redirects
    
    [ Upstream commit 57644431a6c2faac5d754ebd35780cf43a531b1a ]
    
    In commit b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and
    rate_tokens usage") I missed the fact that a 0 'rate_tokens' will
    bypass the backoff algorithm.
    
    Since rate_tokens is cleared after a redirect silence, and never
    incremented on redirects, if the host keeps receiving packets
    requiring redirect it will reply ignoring the backoff.
    
    Additionally, the 'rate_last' field will be updated with the
    cadence of the ingress packet requiring redirect. If that rate is
    high enough, that will prevent the host from generating any
    other kind of ICMP messages
    
    The check for a zero 'rate_tokens' value was likely a shortcut
    to avoid the more complex backoff algorithm after a redirect
    silence period. Address the issue checking for 'n_redirects'
    instead, which is incremented on successful redirect, and
    does not interfere with other ICMP replies.
    
    Fixes: b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage")
    Reported-and-tested-by: Colin Walters <walters@redhat.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62b4ebf58fe989b00164e167421c1da0ad0b69e9
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Thu May 7 12:19:03 2020 -0700

    net: fix a potential recursive NETDEV_FEAT_CHANGE
    
    [ Upstream commit dd912306ff008891c82cd9f63e8181e47a9cb2fb ]
    
    syzbot managed to trigger a recursive NETDEV_FEAT_CHANGE event
    between bonding master and slave. I managed to find a reproducer
    for this:
    
      ip li set bond0 up
      ifenslave bond0 eth0
      brctl addbr br0
      ethtool -K eth0 lro off
      brctl addif br0 bond0
      ip li set br0 up
    
    When a NETDEV_FEAT_CHANGE event is triggered on a bonding slave,
    it captures this and calls bond_compute_features() to fixup its
    master's and other slaves' features. However, when syncing with
    its lower devices by netdev_sync_lower_features() this event is
    triggered again on slaves when the LRO feature fails to change,
    so it goes back and forth recursively until the kernel stack is
    exhausted.
    
    Commit 17b85d29e82c intentionally lets __netdev_update_features()
    return -1 for such a failure case, so we have to just rely on
    the existing check inside netdev_sync_lower_features() and skip
    NETDEV_FEAT_CHANGE event only for this specific failure case.
    
    Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
    Reported-by: syzbot+e73ceacfd8560cc8a3ca@syzkaller.appspotmail.com
    Reported-by: syzbot+c2fb6f9ddcea95ba49b5@syzkaller.appspotmail.com
    Cc: Jarod Wilson <jarod@redhat.com>
    Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Jann Horn <jannh@google.com>
    Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a1dbe631797181cee70c6333bfd77a86c611c19
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 15:58:04 2020 -0700

    gcc-10: avoid shadowing standard library 'free()' in crypto
    
    commit 1a263ae60b04de959d9ce9caea4889385eefcc7b upstream.
    
    gcc-10 has started warning about conflicting types for a few new
    built-in functions, particularly 'free()'.
    
    This results in warnings like:
    
       crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]
    
    because the crypto layer had its local freeing functions called
    'free()'.
    
    Gcc-10 is in the wrong here, since that function is marked 'static', and
    thus there is no chance of confusion with any standard library function
    namespace.
    
    But the simplest thing to do is to just use a different name here, and
    avoid this gcc mis-feature.
    
    [ Side note: gcc knowing about 'free()' is in itself not the
      mis-feature: the semantics of 'free()' are special enough that a
      compiler can validly do special things when seeing it.
    
      So the mis-feature here is that gcc thinks that 'free()' is some
      restricted name, and you can't shadow it as a local static function.
    
      Making the special 'free()' semantics be a function attribute rather
      than tied to the name would be the much better model ]
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16ff1ecfbac80f1fd79ab5a382f0ad81c0d17c1d
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Thu Nov 19 16:55:46 2015 -0500

    x86/paravirt: Remove the unused irq_enable_sysexit pv op
    
    commit 88c15ec90ff16880efab92b519436ee17b198477 upstream.
    
    As result of commit "x86/xen: Avoid fast syscall path for Xen PV
    guests", the irq_enable_sysexit pv op is not called by Xen PV guests
    anymore and since they were the only ones who used it we can
    safely remove it.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Acked-by: Andy Lutomirski <luto@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: david.vrabel@citrix.com
    Cc: konrad.wilk@oracle.com
    Cc: virtualization@lists.linux-foundation.org
    Cc: xen-devel@lists.xenproject.org
    Link: http://lkml.kernel.org/r/1447970147-1733-3-git-send-email-boris.ostrovsky@oracle.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4764810c454478029cb9acf0866d1aec3fccb689
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Sep 25 10:36:20 2018 -0600

    blk-mq: Allow blocking queue tag iter callbacks
    
    commit 530ca2c9bd6949c72c9b5cfc330cb3dbccaa3f5b upstream.
    
    A recent commit runs tag iterator callbacks under the rcu read lock,
    but existing callbacks do not satisfy the non-blocking requirement.
    The commit intended to prevent an iterator from accessing a queue that's
    being modified. This patch fixes the original issue by taking a queue
    reference instead of reading it, which allows callbacks to make blocking
    calls.
    
    Fixes: f5bbbbe4d6357 ("blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter")
    Acked-by: Jianchao Wang <jianchao.w.wang@oracle.com>
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Giuliano Procida <gprocida@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa9355afd5b07707e15a5f75b854f04a9c14a798
Author: Jianchao Wang <jianchao.w.wang@oracle.com>
Date:   Tue Aug 21 15:15:04 2018 +0800

    blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter
    
    commit f5bbbbe4d63577026f908a809f22f5fd5a90ea1f upstream.
    
    For blk-mq, part_in_flight/rw will invoke blk_mq_in_flight/rw to
    account the inflight requests. It will access the queue_hw_ctx and
    nr_hw_queues w/o any protection. When updating nr_hw_queues and
    blk_mq_in_flight/rw occur concurrently, panic comes up.
    
    Before update nr_hw_queues, the q will be frozen. So we could use
    q_usage_counter to avoid the race. percpu_ref_is_zero is used here
    so that we will not miss any in-flight request. The access to
    nr_hw_queues and queue_hw_ctx in blk_mq_queue_tag_busy_iter are
    under rcu critical section, __blk_mq_update_nr_hw_queues could use
    synchronize_rcu to ensure the zeroed q_usage_counter to be globally
    visible.
    
    --------------
    NOTE: Back-ported to 4.4.y.
    
    The upstream commit was intended to prevent concurrent manipulation of
    nr_hw_queues and iteration over queues. The former doesn't happen in
    this in 4.4.7 (as __blk_mq_update_nr_hw_queues doesn't exist). The
    extra locking is also buggy in this commit but fixed in a follow-up.
    
    It may protect against other concurrent accesses such as queue removal
    by synchronising RCU locking around q_usage_counter.
    --------------
    
    Signed-off-by: Jianchao Wang <jianchao.w.wang@oracle.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Giuliano Procida <gprocida@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f06f7a923d1de2542cdcc5a9a157df5eb072913b
Author: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Date:   Mon Aug 1 08:23:39 2016 -0600

    blk-mq: Allow timeouts to run while queue is freezing
    
    commit 71f79fb3179e69b0c1448a2101a866d871c66e7f upstream.
    
    In case a submitted request gets stuck for some reason, the block layer
    can prevent the request starvation by starting the scheduled timeout work.
    If this stuck request occurs at the same time another thread has started
    a queue freeze, the blk_mq_timeout_work will not be able to acquire the
    queue reference and will return silently, thus not issuing the timeout.
    But since the request is already holding a q_usage_counter reference and
    is unable to complete, it will never release its reference, preventing
    the queue from completing the freeze started by first thread.  This puts
    the request_queue in a hung state, forever waiting for the freeze
    completion.
    
    This was observed while running IO to a NVMe device at the same time we
    toggled the CPU hotplug code. Eventually, once a request got stuck
    requiring a timeout during a queue freeze, we saw the CPU Hotplug
    notification code get stuck inside blk_mq_freeze_queue_wait, as shown in
    the trace below.
    
    [c000000deaf13690] [c000000deaf13738] 0xc000000deaf13738 (unreliable)
    [c000000deaf13860] [c000000000015ce8] __switch_to+0x1f8/0x350
    [c000000deaf138b0] [c000000000ade0e4] __schedule+0x314/0x990
    [c000000deaf13940] [c000000000ade7a8] schedule+0x48/0xc0
    [c000000deaf13970] [c0000000005492a4] blk_mq_freeze_queue_wait+0x74/0x110
    [c000000deaf139e0] [c00000000054b6a8] blk_mq_queue_reinit_notify+0x1a8/0x2e0
    [c000000deaf13a40] [c0000000000e7878] notifier_call_chain+0x98/0x100
    [c000000deaf13a90] [c0000000000b8e08] cpu_notify_nofail+0x48/0xa0
    [c000000deaf13ac0] [c0000000000b92f0] _cpu_down+0x2a0/0x400
    [c000000deaf13b90] [c0000000000b94a8] cpu_down+0x58/0xa0
    [c000000deaf13bc0] [c0000000006d5dcc] cpu_subsys_offline+0x2c/0x50
    [c000000deaf13bf0] [c0000000006cd244] device_offline+0x104/0x140
    [c000000deaf13c30] [c0000000006cd40c] online_store+0x6c/0xc0
    [c000000deaf13c80] [c0000000006c8c78] dev_attr_store+0x68/0xa0
    [c000000deaf13cc0] [c0000000003974d0] sysfs_kf_write+0x80/0xb0
    [c000000deaf13d00] [c0000000003963e8] kernfs_fop_write+0x188/0x200
    [c000000deaf13d50] [c0000000002e0f6c] __vfs_write+0x6c/0xe0
    [c000000deaf13d90] [c0000000002e1ca0] vfs_write+0xc0/0x230
    [c000000deaf13de0] [c0000000002e2cdc] SyS_write+0x6c/0x110
    [c000000deaf13e30] [c000000000009204] system_call+0x38/0xb4
    
    The fix is to allow the timeout work to execute in the window between
    dropping the initial refcount reference and the release of the last
    reference, which actually marks the freeze completion.  This can be
    achieved with percpu_refcount_tryget, which does not require the counter
    to be alive.  This way the timeout work can do it's job and terminate a
    stuck request even during a freeze, returning its reference and avoiding
    the deadlock.
    
    Allowing the timeout to run is just a part of the fix, since for some
    devices, we might get stuck again inside the device driver's timeout
    handler, should it attempt to allocate a new request in that path -
    which is a quite common action for Abort commands, which need to be sent
    after a timeout.  In NVMe, for instance, we call blk_mq_alloc_request
    from inside the timeout handler, which will fail during a freeze, since
    it also tries to acquire a queue reference.
    
    I considered a similar change to blk_mq_alloc_request as a generic
    solution for further device driver hangs, but we can't do that, since it
    would allow new requests to disturb the freeze process.  I thought about
    creating a new function in the block layer to support unfreezable
    requests for these occasions, but after working on it for a while, I
    feel like this should be handled in a per-driver basis.  I'm now
    experimenting with changes to the NVMe timeout path, but I'm open to
    suggestions of ways to make this generic.
    
    Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
    Cc: Brian King <brking@linux.vnet.ibm.com>
    Cc: Keith Busch <keith.busch@intel.com>
    Cc: linux-nvme@lists.infradead.org
    Cc: linux-block@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Giuliano Procida <gprocida@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fb835b9561f30188a3bfb5e66295c13348752b9
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Oct 30 20:57:30 2015 +0800

    block: defer timeouts to a workqueue
    
    commit 287922eb0b186e2a5bf54fdd04b734c25c90035c upstream.
    
    Timer context is not very useful for drivers to perform any meaningful abort
    action from.  So instead of calling the driver from this useless context
    defer it to a workqueue as soon as possible.
    
    Note that while a delayed_work item would seem the right thing here I didn't
    dare to use it due to the magic in blk_add_timer that pokes deep into timer
    internals.  But maybe this encourages Tejun to add a sensible API for that to
    the workqueue API and we'll all be fine in the end :)
    
    Contains a major update from Keith Bush:
    
    "This patch removes synchronizing the timeout work so that the timer can
     start a freeze on its own queue. The timer enters the queue, so timer
     context can only start a freeze, but not wait for frozen."
    
    -------------
    NOTE: Back-ported to 4.4.y.
    
    The only parts of the upstream commit that have been kept are various
    locking changes, none of which were mentioned in the original commit
    message which therefore describes this change not at all.
    
    Timeout callbacks continue to be run via a timer. Both blk_mq_rq_timer
    and blk_rq_timed_out_timer will return without without doing any work
    if they cannot acquire the queue (without waiting).
    -------------
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Giuliano Procida <gprocida@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 030a196c1da44102789cb2a8b0695eeada65d53f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 15:45:21 2020 -0700

    gcc-10: disable 'restrict' warning for now
    
    commit adc71920969870dfa54e8f40dac8616284832d02 upstream.
    
    gcc-10 now warns about passing aliasing pointers to functions that take
    restricted pointers.
    
    That's actually a great warning, and if we ever start using 'restrict'
    in the kernel, it might be quite useful.  But right now we don't, and it
    turns out that the only thing this warns about is an idiom where we have
    declared a few functions to be "printf-like" (which seems to make gcc
    pick up the restricted pointer thing), and then we print to the same
    buffer that we also use as an input.
    
    And people do that as an odd concatenation pattern, with code like this:
    
        #define sysfs_show_gen_prop(buffer, fmt, ...) \
            snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)
    
    where we have 'buffer' as both the destination of the final result, and
    as the initial argument.
    
    Yes, it's a bit questionable.  And outside of the kernel, people do have
    standard declarations like
    
        int snprintf( char *restrict buffer, size_t bufsz,
                      const char *restrict format, ... );
    
    where that output buffer is marked as a restrict pointer that cannot
    alias with any other arguments.
    
    But in the context of the kernel, that 'use snprintf() to concatenate to
    the end result' does work, and the pattern shows up in multiple places.
    And we have not marked our own version of snprintf() as taking restrict
    pointers, so the warning is incorrect for now, and gcc picks it up on
    its own.
    
    If we do start using 'restrict' in the kernel (and it might be a good
    idea if people find places where it matters), we'll need to figure out
    how to avoid this issue for snprintf and friends.  But in the meantime,
    this warning is not useful.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a41a8515926d48ec943d329decf5ce694f31b2bb
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 15:40:52 2020 -0700

    gcc-10: disable 'stringop-overflow' warning for now
    
    commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream.
    
    This is the final array bounds warning removal for gcc-10 for now.
    
    Again, the warning is good, and we should re-enable all these warnings
    when we have converted all the legacy array declaration cases to
    flexible arrays. But in the meantime, it's just noise.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c622c6ec05623c8816bb106ec787c695d1db7b3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 14:52:44 2020 -0700

    gcc-10: disable 'array-bounds' warning for now
    
    commit 44720996e2d79e47d508b0abe99b931a726a3197 upstream.
    
    This is another fine warning, related to the 'zero-length-bounds' one,
    but hitting the same historical code in the kernel.
    
    Because C didn't historically support flexible array members, we have
    code that instead uses a one-sized array, the same way we have cases of
    zero-sized arrays.
    
    The one-sized arrays come from either not wanting to use the gcc
    zero-sized array extension, or from a slight convenience-feature, where
    particularly for strings, the size of the structure now includes the
    allocation for the final NUL character.
    
    So with a "char name[1];" at the end of a structure, you can do things
    like
    
           v = my_malloc(sizeof(struct vendor) + strlen(name));
    
    and avoid the "+1" for the terminator.
    
    Yes, the modern way to do that is with a flexible array, and using
    'offsetof()' instead of 'sizeof()', and adding the "+1" by hand.  That
    also technically gets the size "more correct" in that it avoids any
    alignment (and thus padding) issues, but this is another long-term
    cleanup thing that will not happen for 5.7.
    
    So disable the warning for now, even though it's potentially quite
    useful.  Having a slew of warnings that then hide more urgent new issues
    is not an improvement.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2de6a8a83ff0dd80f163d61fd990c4422838a9b1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 14:30:29 2020 -0700

    gcc-10: disable 'zero-length-bounds' warning for now
    
    commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream.
    
    This is a fine warning, but we still have a number of zero-length arrays
    in the kernel that come from the traditional gcc extension.  Yes, they
    are getting converted to flexible arrays, but in the meantime the gcc-10
    warning about zero-length bounds is very verbose, and is hiding other
    issues.
    
    I missed one actual build failure because it was hidden among hundreds
    of lines of warning.  Thankfully I caught it on the second go before
    pushing things out, but it convinced me that I really need to disable
    the new warnings for now.
    
    We'll hopefully be all done with our conversion to flexible arrays in
    the not too distant future, and we can then re-enable this warning.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f566668e19598755603c8bff327b06499537edfd
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 9 13:57:10 2020 -0700

    Stop the ad-hoc games with -Wno-maybe-initialized
    
    commit 78a5255ffb6a1af189a83e493d916ba1c54d8c75 upstream.
    
    We have some rather random rules about when we accept the
    "maybe-initialized" warnings, and when we don't.
    
    For example, we consider it unreliable for gcc versions < 4.9, but also
    if -O3 is enabled, or if optimizing for size.  And then various kernel
    config options disabled it, because they know that they trigger that
    warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).
    
    And now gcc-10 seems to be introducing a lot of those warnings too, so
    it falls under the same heading as 4.9 did.
    
    At the same time, we have a very straightforward way to _enable_ that
    warning when wanted: use "W=2" to enable more warnings.
    
    So stop playing these ad-hoc games, and just disable that warning by
    default, with the known and straight-forward "if you want to work on the
    extra compiler warnings, use W=123".
    
    Would it be great to have code that is always so obvious that it never
    confuses the compiler whether a variable is used initialized or not?
    Yes, it would.  In a perfect world, the compilers would be smarter, and
    our source code would be simpler.
    
    That's currently not the world we live in, though.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c50c2c2ed69e43ce6459f97daf9efac78e11b8c2
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Thu Feb 21 13:13:38 2019 +0900

    kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
    
    commit b303c6df80c9f8f13785aa83a0471fca7e38b24d upstream.
    
    Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched
    various false positives:
    
     - commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building
       with -Os") turned off this option for -Os.
    
     - commit 815eb71e7149 ("Kbuild: disable 'maybe-uninitialized' warning
       for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for
       CONFIG_PROFILE_ALL_BRANCHES
    
     - commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning
       for "make W=1"") turned off this option for GCC < 4.9
       Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903
    
    I think this looks better by shifting the logic from Makefile to Kconfig.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/350
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd395069dda80b9fe4e9f76cd177c1656431c398
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon May 4 09:16:37 2020 -0700

    gcc-10 warnings: fix low-hanging fruit
    
    commit 9d82973e032e246ff5663c9805fbb5407ae932e3 upstream.
    
    Due to a bug-report that was compiler-dependent, I updated one of my
    machines to gcc-10.  That shows a lot of new warnings.  Happily they
    seem to be mostly the valid kind, but it's going to cause a round of
    churn for getting rid of them..
    
    This is the really low-hanging fruit of removing a couple of zero-sized
    arrays in some core code.  We have had a round of these patches before,
    and we'll have many more coming, and there is nothing special about
    these except that they were particularly trivial, and triggered more
    warnings than most.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14aca7c0ed4960ebc1efb9ada867f52e03d906c2
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Tue Apr 14 12:10:50 2020 -0300

    pnp: Use list_for_each_entry() instead of open coding
    
    commit 01b2bafe57b19d9119413f138765ef57990921ce upstream.
    
    Aside from good practice, this avoids a warning from gcc 10:
    
    ./include/linux/kernel.h:997:3: warning: array subscript -31 is outside array bounds of ‘struct list_head[1]’ [-Warray-bounds]
      997 |  ((type *)(__mptr - offsetof(type, member))); })
          |  ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ./include/linux/list.h:493:2: note: in expansion of macro ‘container_of’
      493 |  container_of(ptr, type, member)
          |  ^~~~~~~~~~~~
    ./include/linux/pnp.h:275:30: note: in expansion of macro ‘list_entry’
      275 | #define global_to_pnp_dev(n) list_entry(n, struct pnp_dev, global_list)
          |                              ^~~~~~~~~~
    ./include/linux/pnp.h:281:11: note: in expansion of macro ‘global_to_pnp_dev’
      281 |  (dev) != global_to_pnp_dev(&pnp_global); \
          |           ^~~~~~~~~~~~~~~~~
    arch/x86/kernel/rtc.c:189:2: note: in expansion of macro ‘pnp_for_each_dev’
      189 |  pnp_for_each_dev(dev) {
    
    Because the common code doesn't cast the starting list_head to the
    containing struct.
    
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    [ rjw: Whitespace adjustments ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b559ea48c89923cf68644e560733bf9da9b27519
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Sun Apr 26 10:59:21 2020 +0300

    IB/mlx4: Test return value of calls to ib_get_cached_pkey
    
    [ Upstream commit 6693ca95bd4330a0ad7326967e1f9bcedd6b0800 ]
    
    In the mlx4_ib_post_send() flow, some functions call ib_get_cached_pkey()
    without checking its return value. If ib_get_cached_pkey() returns an
    error code, these functions should return failure.
    
    Fixes: 1ffeb2eb8be9 ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Fixes: e622f2f4ad21 ("IB: split struct ib_send_wr")
    Link: https://lore.kernel.org/r/20200426075921.130074-1-leon@kernel.org
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5dad703517e43dd47285a8a6dcffc024db88bdf
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 30 23:30:48 2020 +0200

    netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
    
    [ Upstream commit 2c407aca64977ede9b9f35158e919773cae2082f ]
    
    gcc-10 warns around a suspicious access to an empty struct member:
    
    net/netfilter/nf_conntrack_core.c: In function '__nf_conntrack_alloc':
    net/netfilter/nf_conntrack_core.c:1522:9: warning: array subscript 0 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[0]'} [-Wzero-length-bounds]
     1522 |  memset(&ct->__nfct_init_offset[0], 0,
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from net/netfilter/nf_conntrack_core.c:37:
    include/net/netfilter/nf_conntrack.h:90:5: note: while referencing '__nfct_init_offset'
       90 |  u8 __nfct_init_offset[0];
          |     ^~~~~~~~~~~~~~~~~~
    
    The code is correct but a bit unusual. Rework it slightly in a way that
    does not trigger the warning, using an empty struct instead of an empty
    array. There are probably more elegant ways to do this, but this is the
    smallest change.
    
    Fixes: c41884ce0562 ("netfilter: conntrack: avoid zeroing timer")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36f7889943fac3889cf27a7692cba3969eb1d13d
Author: Gal Pressman <galp@mellanox.com>
Date:   Mon Jun 19 18:25:59 2017 +0300

    net/mlx5: Fix driver load error flow when firmware is stuck
    
    [ Upstream commit 8ce59b16b4b6eacedaec1f7b652b4781cdbfe15f ]
    
    When wait for firmware init fails, previous code would mistakenly
    return success and cause inconsistency in the driver state.
    
    Fixes: 6c780a0267b8 ("net/mlx5: Wait for FW readiness before initializing command interface")
    Signed-off-by: Gal Pressman <galp@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 536918c1d68379b820ef0743cbc4fe9755772d63
Author: Anjali Singhai Jain <anjali.singhai@intel.com>
Date:   Fri Sep 1 13:42:49 2017 -0700

    i40e: avoid NVM acquire deadlock during NVM update
    
    [ Upstream commit 09f79fd49d94cda5837e9bfd0cb222232b3b6d9f ]
    
    X722 devices use the AdminQ to access the NVM, and this requires taking
    the AdminQ lock. Because of this, we lock the AdminQ during
    i40e_read_nvm(), which is also called in places where the lock is
    already held, such as the firmware update path which wants to lock once
    and then unlock when finished after performing several tasks.
    
    Although this should have only affected X722 devices, commit
    96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
    2016-12-02) added locking for all NVM reads, regardless of device
    family.
    
    This resulted in us accidentally causing NVM acquire timeouts on all
    devices, causing failed firmware updates which left the eeprom in
    a corrupt state.
    
    Create unsafe non-locked variants of i40e_read_nvm_word and
    i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer
    respectively. These variants will not take the NVM lock and are expected
    to only be called in places where the NVM lock is already held if
    needed.
    
    Since the only caller of i40e_read_nvm_buffer() was in such a path,
    remove it entirely in favor of the unsafe version. If necessary we can
    always add it back in the future.
    
    Additionally, we now need to hold the NVM lock in i40e_validate_checksum
    because the call to i40e_calc_nvm_checksum now assumes that the NVM lock
    is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD
    up a bit so that we do not need to acquire the NVM lock twice.
    
    This should resolve firmware updates and also fix potential raise that
    could have caused the driver to report an invalid NVM checksum upon
    driver load.
    
    Reported-by: Stefan Assmann <sassmann@kpanic.de>
    Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices", 2016-12-02)
    Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bde533c656f3d736545677c73413f30f2ece3bbd
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Tue Mar 20 21:05:48 2018 +0000

    scsi: qla2xxx: Avoid double completion of abort command
    
    [ Upstream commit 3a9910d7b686546dcc9986e790af17e148f1c888 ]
    
    qla2x00_tmf_sp_done() now deletes the timer that will run
    qla2x00_tmf_iocb_timeout(), but doesn't check whether the timer already
    expired.  Check the return value from del_timer() to avoid calling
    complete() a second time.
    
    Fixes: 4440e46d5db7 ("[SCSI] qla2xxx: Add IOCB Abort command asynchronous ...")
    Fixes: 1514839b3664 ("scsi: qla2xxx: Fix NULL pointer crash due to active ...")
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a3c1ab554378c904e9e59de33569e5f691ca0eb
Author: zhong jiang <zhongjiang@huawei.com>
Date:   Fri Feb 24 14:59:30 2017 -0800

    mm/memory_hotplug.c: fix overflow in test_pages_in_a_zone()
    
    [ Upstream commit d6d8c8a48291b929b2e039f220f0b62958cccfea ]
    
    When mainline introduced commit a96dfddbcc04 ("base/memory, hotplug: fix
    a kernel oops in show_valid_zones()"), it obtained the valid start and
    end pfn from the given pfn range.  The valid start pfn can fix the
    actual issue, but it introduced another issue.  The valid end pfn will
    may exceed the given end_pfn.
    
    Although the incorrect overflow will not result in actual problem at
    present, but I think it need to be fixed.
    
    [toshi.kani@hpe.com: remove assumption that end_pfn is aligned by MAX_ORDER_NR_PAGES]
    Fixes: a96dfddbcc04 ("base/memory, hotplug: fix a kernel oops in show_valid_zones()")
    Link: http://lkml.kernel.org/r/1486467299-22648-1-git-send-email-zhongjiang@huawei.com
    Signed-off-by: zhong jiang <zhongjiang@huawei.com>
    Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ac3143d79ebec3f4b1114845a37b98299c23319
Author: Jiri Benc <jbenc@redhat.com>
Date:   Wed May 11 15:53:57 2016 +0200

    gre: do not keep the GRE header around in collect medata mode
    
    [ Upstream commit e271c7b4420ddbb9fae82a2b31a5ab3edafcf4fe ]
    
    For ipgre interface in collect metadata mode, it doesn't make sense for the
    interface to be of ARPHRD_IPGRE type. The outer header of received packets
    is not needed, as all the information from it is present in metadata_dst. We
    already don't set ipgre_header_ops for collect metadata interfaces, which is
    the only consumer of mac_header pointing to the outer IP header.
    
    Just set the interface type to ARPHRD_NONE in collect metadata mode for
    ipgre (not gretap, that still correctly stays ARPHRD_ETHER) and reset
    mac_header.
    
    Fixes: a64b04d86d14 ("gre: do not assign header_ops in collect metadata mode")
    Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 887daaacb5415b63dbc91a7977d2f9f6b820cd26
Author: John Hurley <john.hurley@netronome.com>
Date:   Thu Jun 27 14:37:30 2019 +0100

    net: openvswitch: fix csum updates for MPLS actions
    
    [ Upstream commit 0e3183cd2a64843a95b62f8bd4a83605a4cf0615 ]
    
    Skbs may have their checksum value populated by HW. If this is a checksum
    calculated over the entire packet then the CHECKSUM_COMPLETE field is
    marked. Changes to the data pointer on the skb throughout the network
    stack still try to maintain this complete csum value if it is required
    through functions such as skb_postpush_rcsum.
    
    The MPLS actions in Open vSwitch modify a CHECKSUM_COMPLETE value when
    changes are made to packet data without a push or a pull. This occurs when
    the ethertype of the MAC header is changed or when MPLS lse fields are
    modified.
    
    The modification is carried out using the csum_partial function to get the
    csum of a buffer and add it into the larger checksum. The buffer is an
    inversion of the data to be removed followed by the new data. Because the
    csum is calculated over 16 bits and these values align with 16 bits, the
    effect is the removal of the old value from the CHECKSUM_COMPLETE and
    addition of the new value.
    
    However, the csum fed into the function and the outcome of the
    calculation are also inverted. This would only make sense if it was the
    new value rather than the old that was inverted in the input buffer.
    
    Fix the issue by removing the bit inverts in the csum_partial calculation.
    
    The bug was verified and the fix tested by comparing the folded value of
    the updated CHECKSUM_COMPLETE value with the folded value of a full
    software checksum calculation (reset skb->csum to 0 and run
    skb_checksum_complete(skb)). Prior to the fix the outcomes differed but
    after they produce the same result.
    
    Fixes: 25cd9ba0abc0 ("openvswitch: Add basic MPLS support to kernel")
    Fixes: bc7cc5999fd3 ("openvswitch: update checksum in {push,pop}_mpls")
    Signed-off-by: John Hurley <john.hurley@netronome.com>
    Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reviewed-by: Simon Horman <simon.horman@netronome.com>
    Acked-by: Pravin B Shelar <pshelar@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 77dbb2fa31d5e76dc8b16bdc737f293ad17b7b49
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Wed May 13 17:50:48 2020 -0700

    ipc/util.c: sysvipc_find_ipc() incorrectly updates position index
    
    [ Upstream commit 5e698222c70257d13ae0816720dde57c56f81e15 ]
    
    Commit 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase
    position index") is causing this bug (seen on 5.6.8):
    
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
    
       # ipcmk -Q
       Message queue id: 0
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
       0x82db8127 0          root       644        0            0
    
       # ipcmk -Q
       Message queue id: 1
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
       0x82db8127 0          root       644        0            0
       0x76d1fb2a 1          root       644        0            0
    
       # ipcrm -q 0
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
       0x76d1fb2a 1          root       644        0            0
       0x76d1fb2a 1          root       644        0            0
    
       # ipcmk -Q
       Message queue id: 2
       # ipcrm -q 2
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
       0x76d1fb2a 1          root       644        0            0
       0x76d1fb2a 1          root       644        0            0
    
       # ipcmk -Q
       Message queue id: 3
       # ipcrm -q 1
       # ipcs -q
    
       ------ Message Queues --------
       key        msqid      owner      perms      used-bytes   messages
       0x7c982867 3          root       644        0            0
       0x7c982867 3          root       644        0            0
       0x7c982867 3          root       644        0            0
       0x7c982867 3          root       644        0            0
    
    Whenever an IPC item with a low id is deleted, the items with higher ids
    are duplicated, as if filling a hole.
    
    new_pos should jump through hole of unused ids, pos can be updated
    inside "for" cycle.
    
    Fixes: 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index")
    Reported-by: Andreas Schwab <schwab@suse.de>
    Reported-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Waiman Long <longman@redhat.com>
    Cc: NeilBrown <neilb@suse.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Cc: <stable@vger.kernel.org>
    Link: http://lkml.kernel.org/r/4921fe9b-9385-a2b4-1dc4-1099be6d2e39@virtuozzo.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac8087ffca52294d4f8ab043d895f013c340539e
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Wed Apr 29 12:34:36 2020 +0300

    drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()
    
    [ Upstream commit 5b5703dbafae74adfbe298a56a81694172caf5e6 ]
    
    v2: removed TODO reminder
    
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/a4e0ae09-a73c-1c62-04ef-3f990d41bea9@virtuozzo.com
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4db73f4467eaf97eabd4f763ba51c05dda87f8b1
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Sun Apr 19 18:49:09 2020 +0200

    dmaengine: mmp_tdma: Reset channel error on release
    
    [ Upstream commit 0c89446379218698189a47871336cb30286a7197 ]
    
    When a channel configuration fails, the status of the channel is set to
    DEV_ERROR so that an attempt to submit it fails. However, this status
    sticks until the heat end of the universe, making it impossible to
    recover from the error.
    
    Let's reset it when the channel is released so that further use of the
    channel with correct configuration is not impacted.
    
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Link: https://lore.kernel.org/r/20200419164912.670973-5-lkundrak@v3.sk
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 329a8c9d417bb2cf822be633dd2b4c5d77cd1586
Author: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Date:   Thu Apr 16 11:53:35 2020 +0530

    dmaengine: pch_dma.c: Avoid data race between probe and irq handler
    
    [ Upstream commit 2e45676a4d33af47259fa186ea039122ce263ba9 ]
    
    pd->dma.dev is read in irq handler pd_irq().
    However, it is set to pdev->dev after request_irq().
    Therefore, set pd->dma.dev to pdev->dev before request_irq() to
    avoid data race between pch_dma_probe() and pd_irq().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
    Link: https://lore.kernel.org/r/20200416062335.29223-1-madhuparnabhowmik10@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41f53bf3898ad11862777aab420b55d8a6dc844d
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Sat Jul 6 06:52:46 2019 +1000

    cifs: Fix a race condition with cifs_echo_request
    
    [ Upstream commit f2caf901c1b7ce65f9e6aef4217e3241039db768 ]
    
    There is a race condition with how we send (or supress and don't send)
    smb echos that will cause the client to incorrectly think the
    server is unresponsive and thus needs to be reconnected.
    
    Summary of the race condition:
     1) Daisy chaining scheduling creates a gap.
     2) If traffic comes unfortunate shortly after
        the last echo, the planned echo is suppressed.
     3) Due to the gap, the next echo transmission is delayed
        until after the timeout, which is set hard to twice
        the echo interval.
    
    This is fixed by changing the timeouts from 2 to three times the echo interval.
    
    Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remount
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd63cf20b2df90412275daf08cd6fe422209ae8
Author: Samuel Cabrero <scabrero@suse.de>
Date:   Tue Jul 11 12:44:39 2017 +0200

    cifs: Check for timeout on Negotiate stage
    
    [ Upstream commit 76e752701a8af4404bbd9c45723f7cbd6e4a251e ]
    
    Some servers seem to accept connections while booting but never send
    the SMBNegotiate response neither close the connection, causing all
    processes accessing the share hang on uninterruptible sleep state.
    
    This happens when the cifs_demultiplex_thread detects the server is
    unresponsive so releases the socket and start trying to reconnect.
    At some point, the faulty server will accept the socket and the TCP
    status will be set to NeedNegotiate. The first issued command accessing
    the share will start the negotiation (pid 5828 below), but the response
    will never arrive so other commands will be blocked waiting on the mutex
    (pid 55352).
    
    This patch checks for unresponsive servers also on the negotiate stage
    releasing the socket and reconnecting if the response is not received
    and checking again the tcp state when the mutex is acquired.
    
    PID: 55352  TASK: ffff880fd6cc02c0  CPU: 0   COMMAND: "ls"
     #0 [ffff880fd9add9f0] schedule at ffffffff81467eb9
     #1 [ffff880fd9addb38] __mutex_lock_slowpath at ffffffff81468fe0
     #2 [ffff880fd9addba8] mutex_lock at ffffffff81468b1a
     #3 [ffff880fd9addbc0] cifs_reconnect_tcon at ffffffffa042f905 [cifs]
     #4 [ffff880fd9addc60] smb_init at ffffffffa042faeb [cifs]
     #5 [ffff880fd9addca0] CIFSSMBQPathInfo at ffffffffa04360b5 [cifs]
     ....
    
    Which is waiting a mutex owned by:
    
    PID: 5828   TASK: ffff880fcc55e400  CPU: 0   COMMAND: "xxxx"
     #0 [ffff880fbfdc19b8] schedule at ffffffff81467eb9
     #1 [ffff880fbfdc1b00] wait_for_response at ffffffffa044f96d [cifs]
     #2 [ffff880fbfdc1b60] SendReceive at ffffffffa04505ce [cifs]
     #3 [ffff880fbfdc1bb0] CIFSSMBNegotiate at ffffffffa0438d79 [cifs]
     #4 [ffff880fbfdc1c50] cifs_negotiate_protocol at ffffffffa043b383 [cifs]
     #5 [ffff880fbfdc1c80] cifs_reconnect_tcon at ffffffffa042f911 [cifs]
     #6 [ffff880fbfdc1d20] smb_init at ffffffffa042faeb [cifs]
     #7 [ffff880fbfdc1d60] CIFSSMBQFSInfo at ffffffffa0434eb0 [cifs]
     ....
    
    Signed-off-by: Samuel Cabrero <scabrero@suse.de>
    Reviewed-by: Aurélien Aptel <aaptel@suse.de>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3549e7aaa20947df2338305509c534c79c43e765
Author: wuxu.wu <wuxu.wu@huawei.com>
Date:   Wed Jan 1 11:39:41 2020 +0800

    spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent calls
    
    commit 19b61392c5a852b4e8a0bf35aecb969983c5932d upstream.
    
    dw_spi_irq() and dw_spi_transfer_one concurrent calls.
    
    I find a panic in dw_writer(): txw = *(u8 *)(dws->tx), when dw->tx==null,
    dw->len==4, and dw->tx_end==1.
    
    When tpm driver's message overtime dw_spi_irq() and dw_spi_transfer_one
    may concurrent visit dw_spi, so I think dw_spi structure lack of protection.
    
    Otherwise dw_spi_transfer_one set dw rx/tx buffer and then open irq,
    store dw rx/tx instructions and other cores handle irq load dw rx/tx
    instructions may out of order.
    
            [ 1025.321302] Call trace:
            ...
            [ 1025.321319]  __crash_kexec+0x98/0x148
            [ 1025.321323]  panic+0x17c/0x314
            [ 1025.321329]  die+0x29c/0x2e8
            [ 1025.321334]  die_kernel_fault+0x68/0x78
            [ 1025.321337]  __do_kernel_fault+0x90/0xb0
            [ 1025.321346]  do_page_fault+0x88/0x500
            [ 1025.321347]  do_translation_fault+0xa8/0xb8
            [ 1025.321349]  do_mem_abort+0x68/0x118
            [ 1025.321351]  el1_da+0x20/0x8c
            [ 1025.321362]  dw_writer+0xc8/0xd0
            [ 1025.321364]  interrupt_transfer+0x60/0x110
            [ 1025.321365]  dw_spi_irq+0x48/0x70
            ...
    
    Signed-off-by: wuxu.wu <wuxu.wu@huawei.com>
    Link: https://lore.kernel.org/r/1577849981-31489-1-git-send-email-wuxu.wu@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af9a86cc9f1acfc380e96a9beb59462f32a4b6c4
Author: Wu Bo <wubo40@huawei.com>
Date:   Tue Apr 14 10:13:28 2020 +0800

    scsi: sg: add sg_remove_request in sg_write
    
    commit 83c6f2390040f188cc25b270b4befeb5628c1aee upstream.
    
    If the __copy_from_user function failed we need to call sg_remove_request
    in sg_write.
    
    Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Wu Bo <wubo40@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    [groeck: Backport to v5.4.y and older kernels]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd00b981447eb5dd4f613fbd8611448907682b4c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 30 23:30:49 2020 +0200

    drop_monitor: work around gcc-10 stringop-overflow warning
    
    [ Upstream commit dc30b4059f6e2abf3712ab537c8718562b21c45d ]
    
    The current gcc-10 snapshot produces a false-positive warning:
    
    net/core/drop_monitor.c: In function 'trace_drop_common.constprop':
    cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
    In file included from net/core/drop_monitor.c:23:
    include/uapi/linux/net_dropmon.h:36:8: note: at offset 0 to object 'entries' with size 4 declared here
       36 |  __u32 entries;
          |        ^~~~~~~
    
    I reported this in the gcc bugzilla, but in case it does not get
    fixed in the release, work around it by using a temporary variable.
    
    Fixes: 9a8afc8d3962 ("Network Drop Monitor: Adding drop monitor implementation & Netlink protocol")
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ad07995cd9bb354d4d6d3c9964519c67c3edbbf
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Apr 26 22:59:21 2020 +0200

    net: moxa: Fix a potential double 'free_irq()'
    
    [ Upstream commit ee8d2267f0e39a1bfd95532da3a6405004114b27 ]
    
    Should an irq requested with 'devm_request_irq' be released explicitly,
    it should be done by 'devm_free_irq()', not 'free_irq()'.
    
    Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c8c200bba4a736a13a933764820597939f2b312
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Apr 27 08:18:03 2020 +0200

    net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'
    
    [ Upstream commit 10e3cc180e64385edc9890c6855acf5ed9ca1339 ]
    
    A call to 'dma_alloc_coherent()' is hidden in 'sonic_alloc_descriptors()',
    called from 'sonic_probe1()'.
    
    This is correctly freed in the remove function, but not in the error
    handling path of the probe function.
    Fix it and add the missing 'dma_free_coherent()' call.
    
    While at it, rename a label in order to be slightly more informative.
    
    Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 178af2f97dcaea27611f0420ec7b61c1a27d6776
Author: David Ahern <dsa@cumulusnetworks.com>
Date:   Sun Nov 27 18:52:53 2016 -0800

    net: handle no dst on skb in icmp6_send
    
    commit 79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 upstream.
    
    Andrey reported the following while fuzzing the kernel with syzkaller:
    
    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] SMP KASAN
    Modules linked in:
    CPU: 0 PID: 3859 Comm: a.out Not tainted 4.9.0-rc6+ #429
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff8800666d4200 task.stack: ffff880067348000
    RIP: 0010:[<ffffffff833617ec>]  [<ffffffff833617ec>]
    icmp6_send+0x5fc/0x1e30 net/ipv6/icmp.c:451
    RSP: 0018:ffff88006734f2c0  EFLAGS: 00010206
    RAX: ffff8800666d4200 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000018
    RBP: ffff88006734f630 R08: ffff880064138418 R09: 0000000000000003
    R10: dffffc0000000000 R11: 0000000000000005 R12: 0000000000000000
    R13: ffffffff84e7e200 R14: ffff880064138484 R15: ffff8800641383c0
    FS:  00007fb3887a07c0(0000) GS:ffff88006cc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000000 CR3: 000000006b040000 CR4: 00000000000006f0
    Stack:
     ffff8800666d4200 ffff8800666d49f8 ffff8800666d4200 ffffffff84c02460
     ffff8800666d4a1a 1ffff1000ccdaa2f ffff88006734f498 0000000000000046
     ffff88006734f440 ffffffff832f4269 ffff880064ba7456 0000000000000000
    Call Trace:
     [<ffffffff83364ddc>] icmpv6_param_prob+0x2c/0x40 net/ipv6/icmp.c:557
     [<     inline     >] ip6_tlvopt_unknown net/ipv6/exthdrs.c:88
     [<ffffffff83394405>] ip6_parse_tlv+0x555/0x670 net/ipv6/exthdrs.c:157
     [<ffffffff8339a759>] ipv6_parse_hopopts+0x199/0x460 net/ipv6/exthdrs.c:663
     [<ffffffff832ee773>] ipv6_rcv+0xfa3/0x1dc0 net/ipv6/ip6_input.c:191
     ...
    
    icmp6_send / icmpv6_send is invoked for both rx and tx paths. In both
    cases the dst->dev should be preferred for determining the L3 domain
    if the dst has been set on the skb. Fallback to the skb->dev if it has
    not. This covers the case reported here where icmp6_send is invoked on
    Rx before the route lookup.
    
    Fixes: 5d41ce29e ("net: icmp6_send should use dst dev to determine L3 domain")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9acf25d6c38acbf428130d092c7048f4510ae82
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Mon Jan 13 14:00:09 2020 +0100

    ptp: free ptp device pin descriptors properly
    
    commit 75718584cb3c64e6269109d4d54f888ac5a5fd15 upstream.
    
    There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups()
    first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs
    them to destroy a related sysfs device.
    
    These functions can not be just swapped, as posix_clock_unregister() frees
    ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling
    ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed.
    
    This makes this patch fix an UAF bug in a patch which fixes an UAF bug.
    
    Reported-by: Antti Laakso <antti.laakso@intel.com>
    Fixes: a33121e5487b ("ptp: fix the race between the release of ptp_clock and cdev")
    Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f5e3bb7879ee1eb71c6c3cbaaffbb0da6cd7d57
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Fri Dec 27 03:26:27 2019 +0100

    ptp: fix the race between the release of ptp_clock and cdev
    
    commit a33121e5487b424339636b25c35d3a180eaa5f5e upstream.
    
    In a case when a ptp chardev (like /dev/ptp0) is open but an underlying
    device is removed, closing this file leads to a race. This reproduces
    easily in a kvm virtual machine:
    
    ts# cat openptp0.c
    int main() { ... fp = fopen("/dev/ptp0", "r"); ... sleep(10); }
    ts# uname -r
    5.5.0-rc3-46cf053e
    ts# cat /proc/cmdline
    ... slub_debug=FZP
    ts# modprobe ptp_kvm
    ts# ./openptp0 &
    [1] 670
    opened /dev/ptp0, sleeping 10s...
    ts# rmmod ptp_kvm
    ts# ls /dev/ptp*
    ls: cannot access '/dev/ptp*': No such file or directory
    ts# ...woken up
    [   48.010809] general protection fault: 0000 [#1] SMP
    [   48.012502] CPU: 6 PID: 658 Comm: openptp0 Not tainted 5.5.0-rc3-46cf053e #25
    [   48.014624] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...
    [   48.016270] RIP: 0010:module_put.part.0+0x7/0x80
    [   48.017939] RSP: 0018:ffffb3850073be00 EFLAGS: 00010202
    [   48.018339] RAX: 000000006b6b6b6b RBX: 6b6b6b6b6b6b6b6b RCX: ffff89a476c00ad0
    [   48.018936] RDX: fffff65a08d3ea08 RSI: 0000000000000247 RDI: 6b6b6b6b6b6b6b6b
    [   48.019470] ...                                              ^^^ a slub poison
    [   48.023854] Call Trace:
    [   48.024050]  __fput+0x21f/0x240
    [   48.024288]  task_work_run+0x79/0x90
    [   48.024555]  do_exit+0x2af/0xab0
    [   48.024799]  ? vfs_write+0x16a/0x190
    [   48.025082]  do_group_exit+0x35/0x90
    [   48.025387]  __x64_sys_exit_group+0xf/0x10
    [   48.025737]  do_syscall_64+0x3d/0x130
    [   48.026056]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [   48.026479] RIP: 0033:0x7f53b12082f6
    [   48.026792] ...
    [   48.030945] Modules linked in: ptp i6300esb watchdog [last unloaded: ptp_kvm]
    [   48.045001] Fixing recursive fault but reboot is needed!
    
    This happens in:
    
    static void __fput(struct file *file)
    {   ...
        if (file->f_op->release)
            file->f_op->release(inode, file); <<< cdev is kfree'd here
        if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL &&
                 !(mode & FMODE_PATH))) {
            cdev_put(inode->i_cdev); <<< cdev fields are accessed here
    
    Namely:
    
    __fput()
      posix_clock_release()
        kref_put(&clk->kref, delete_clock) <<< the last reference
          delete_clock()
            delete_ptp_clock()
              kfree(ptp) <<< cdev is embedded in ptp
      cdev_put
        module_put(p->owner) <<< *p is kfree'd, bang!
    
    Here cdev is embedded in posix_clock which is embedded in ptp_clock.
    The race happens because ptp_clock's lifetime is controlled by two
    refcounts: kref and cdev.kobj in posix_clock. This is wrong.
    
    Make ptp_clock's sysfs device a parent of cdev with cdev_device_add()
    created especially for such cases. This way the parent device with its
    ptp_clock is not released until all references to the cdev are released.
    This adds a requirement that an initialized but not exposed struct
    device should be provided to posix_clock_register() by a caller instead
    of a simple dev_t.
    
    This approach was adopted from the commit 72139dfa2464 ("watchdog: Fix
    the race between the release of watchdog_core_data and cdev"). See
    details of the implementation in the commit 233ed09d7fda ("chardev: add
    helper function to register char devs with a struct device").
    
    Link: https://lore.kernel.org/linux-fsdevel/20191125125342.6189-1-vdronov@redhat.com/T/#u
    Analyzed-by: Stephen Johnston <sjohnsto@redhat.com>
    Analyzed-by: Vern Lovejoy <vlovejoy@redhat.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6091936487a95791e24019ad949d11c661700205
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Nov 23 09:54:55 2018 +0800

    ptp: Fix pass zero to ERR_PTR() in ptp_clock_register
    
    commit aea0a897af9e44c258e8ab9296fad417f1bc063a upstream.
    
    Fix smatch warning:
    
    drivers/ptp/ptp_clock.c:298 ptp_clock_register() warn:
     passing zero to 'ERR_PTR'
    
    'err' should be set while device_create_with_groups and
    pps_register_source fails
    
    Fixes: 85a66e550195 ("ptp: create "pins" together with the rest of attributes")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d79d7d5c878809964da537336dad5ff55fa1605e
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Fri Mar 17 12:48:08 2017 -0600

    chardev: add helper function to register char devs with a struct device
    
    commit 233ed09d7fdacf592ee91e6c97ce5f4364fbe7c0 upstream.
    
    Credit for this patch goes is shared with Dan Williams [1]. I've
    taken things one step further to make the helper function more
    useful and clean up calling code.
    
    There's a common pattern in the kernel whereby a struct cdev is placed
    in a structure along side a struct device which manages the life-cycle
    of both. In the naive approach, the reference counting is broken and
    the struct device can free everything before the chardev code
    is entirely released.
    
    Many developers have solved this problem by linking the internal kobjs
    in this fashion:
    
    cdev.kobj.parent = &parent_dev.kobj;
    
    The cdev code explicitly gets and puts a reference to it's kobj parent.
    So this seems like it was intended to be used this way. Dmitrty Torokhov
    first put this in place in 2012 with this commit:
    
    2f0157f char_dev: pin parent kobject
    
    and the first instance of the fix was then done in the input subsystem
    in the following commit:
    
    4a215aa Input: fix use-after-free introduced with dynamic minor changes
    
    Subsequently over the years, however, this issue seems to have tripped
    up multiple developers independently. For example, see these commits:
    
    0d5b7da iio: Prevent race between IIO chardev opening and IIO device
    (by Lars-Peter Clausen in 2013)
    
    ba0ef85 tpm: Fix initialization of the cdev
    (by Jason Gunthorpe in 2015)
    
    5b28dde [media] media: fix use-after-free in cdev_put() when app exits
    after driver unbind
    (by Shauh Khan in 2016)
    
    This technique is similarly done in at least 15 places within the kernel
    and probably should have been done so in another, at least, 5 places.
    The kobj line also looks very suspect in that one would not expect
    drivers to have to mess with kobject internals in this way.
    Even highly experienced kernel developers can be surprised by this
    code, as seen in [2].
    
    To help alleviate this situation, and hopefully prevent future
    wasted effort on this problem, this patch introduces a helper function
    to register a char device along with its parent struct device.
    This creates a more regular API for tying a char device to its parent
    without the developer having to set members in the underlying kobject.
    
    This patch introduce cdev_device_add and cdev_device_del which
    replaces a common pattern including setting the kobj parent, calling
    cdev_add and then calling device_add. It also introduces cdev_set_parent
    for the few cases that set the kobject parent without using device_add.
    
    [1] https://lkml.org/lkml/2017/2/13/700
    [2] https://lkml.org/lkml/2017/2/10/370
    
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
    Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5a654c9935cf48f6b1913e0e1aea81945e1585b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Feb 14 10:23:34 2017 -0800

    ptp: create "pins" together with the rest of attributes
    
    commit 85a66e55019583da1e0f18706b7a8281c9f6de5b upstream.
    
    Let's switch to using device_create_with_groups(), which will allow us to
    create "pins" attribute group together with the rest of ptp device
    attributes, and before userspace gets notified about ptp device creation.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.9: adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e95a7fb08693fe63032bf573c30381c79cd349e1
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Feb 14 10:23:33 2017 -0800

    ptp: use is_visible method to hide unused attributes
    
    commit af59e717d5ff9c8dbf9bcc581c0dfb3b2a9c9030 upstream.
    
    Instead of creating selected attributes after the device is created (and
    after userspace potentially seen uevent), lets use attribute group
    is_visible() method to control which attributes are shown. This will allow
    us to create all attributes (except "pins" group, which will be taken care
    of later) before userspace gets notified about new ptp class device.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f212dbd2b2e84184fd32ac3962d4a3bd770a0db3
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Feb 14 10:23:31 2017 -0800

    ptp: do not explicitly set drvdata in ptp_clock_register()
    
    commit 882f312dc0751c973db26478f07f082c584d16aa upstream.
    
    We do not need explicitly call dev_set_drvdata(), as it is done for us by
    device_create().
    
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab33f6abb29a83adae7fe55889f333d4d35712ed
Author: Cengiz Can <cengiz@kernel.wtf>
Date:   Wed Mar 4 13:58:19 2020 +0300

    blktrace: fix dereference after null check
    
    commit 153031a301bb07194e9c37466cfce8eacb977621 upstream.
    
    There was a recent change in blktrace.c that added a RCU protection to
    `q->blk_trace` in order to fix a use-after-free issue during access.
    
    However the change missed an edge case that can lead to dereferencing of
    `bt` pointer even when it's NULL:
    
    Coverity static analyzer marked this as a FORWARD_NULL issue with CID
    1460458.
    
    ```
    /kernel/trace/blktrace.c: 1904 in sysfs_blk_trace_attr_store()
    1898            ret = 0;
    1899            if (bt == NULL)
    1900                    ret = blk_trace_setup_queue(q, bdev);
    1901
    1902            if (ret == 0) {
    1903                    if (attr == &dev_attr_act_mask)
    >>>     CID 1460458:  Null pointer dereferences  (FORWARD_NULL)
    >>>     Dereferencing null pointer "bt".
    1904                            bt->act_mask = value;
    1905                    else if (attr == &dev_attr_pid)
    1906                            bt->pid = value;
    1907                    else if (attr == &dev_attr_start_lba)
    1908                            bt->start_lba = value;
    1909                    else if (attr == &dev_attr_end_lba)
    ```
    
    Added a reassignment with RCU annotation to fix the issue.
    
    Fixes: c780e86dd48 ("blktrace: Protect q->blk_trace with RCU")
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Bob Liu <bob.liu@oracle.com>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d5d64aea941a45efda1bd02c0ec8dd57e8ce4ca
Author: Jan Kara <jack@suse.cz>
Date:   Thu Feb 6 15:28:12 2020 +0100

    blktrace: Protect q->blk_trace with RCU
    
    commit c780e86dd48ef6467a1146cf7d0fe1e05a635039 upstream.
    
    KASAN is reporting that __blk_add_trace() has a use-after-free issue
    when accessing q->blk_trace. Indeed the switching of block tracing (and
    thus eventual freeing of q->blk_trace) is completely unsynchronized with
    the currently running tracing and thus it can happen that the blk_trace
    structure is being freed just while __blk_add_trace() works on it.
    Protect accesses to q->blk_trace by RCU during tracing and make sure we
    wait for the end of RCU grace period when shutting down tracing. Luckily
    that is rare enough event that we can afford that. Note that postponing
    the freeing of blk_trace to an RCU callback should better be avoided as
    it could have unexpected user visible side-effects as debugfs files
    would be still existing for a short while block tracing has been shut
    down.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=205711
    CC: stable@vger.kernel.org
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reported-by: Tristan Madani <tristmd@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 4.4:
     - Drop changes in blk_trace_note_message_enabled(), blk_trace_bio_get_cgid()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd13258a62313ca9102116d57340d76453297b09
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Nov 19 11:52:55 2017 -0700

    blktrace: fix trace mutex deadlock
    
    commit 2967acbb257a6a9bf912f4778b727e00972eac9b upstream.
    
    A previous commit changed the locking around registration/cleanup,
    but direct callers of blk_trace_remove() were missed. This means
    that if we hit the error path in setup, we will deadlock on
    attempting to re-acquire the queue trace mutex.
    
    Fixes: 1f2cac107c59 ("blktrace: fix unlocked access to init/start-stop/teardown")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e6958563b29d617c443ddc866808f6d83aafb63
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Nov 5 09:13:48 2017 -0700

    blktrace: fix unlocked access to init/start-stop/teardown
    
    commit 1f2cac107c591c24b60b115d6050adc213d10fc0 upstream.
    
    sg.c calls into the blktrace functions without holding the proper queue
    mutex for doing setup, start/stop, or teardown.
    
    Add internal unlocked variants, and export the ones that do the proper
    locking.
    
    Fixes: 6da127ad0918 ("blktrace: Add blktrace ioctls to SCSI generic devices")
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee60ffbceeb0f5d10b5fdbd2f47b268eb41e9d4
Author: Waiman Long <longman@redhat.com>
Date:   Wed Sep 20 13:12:20 2017 -0600

    blktrace: Fix potential deadlock between delete & sysfs ops
    
    commit 5acb3cc2c2e9d3020a4fee43763c6463767f1572 upstream.
    
    The lockdep code had reported the following unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(s_active#228);
                                   lock(&bdev->bd_mutex/1);
                                   lock(s_active#228);
      lock(&bdev->bd_mutex);
    
     *** DEADLOCK ***
    
    The deadlock may happen when one task (CPU1) is trying to delete a
    partition in a block device and another task (CPU0) is accessing
    tracing sysfs file (e.g. /sys/block/dm-1/trace/act_mask) in that
    partition.
    
    The s_active isn't an actual lock. It is a reference count (kn->count)
    on the sysfs (kernfs) file. Removal of a sysfs file, however, require
    a wait until all the references are gone. The reference count is
    treated like a rwsem using lockdep instrumentation code.
    
    The fact that a thread is in the sysfs callback method or in the
    ioctl call means there is a reference to the opended sysfs or device
    file. That should prevent the underlying block structure from being
    removed.
    
    Instead of using bd_mutex in the block_device structure, a new
    blk_trace_mutex is now added to the request_queue structure to protect
    access to the blk_trace structure.
    
    Suggested-by: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Waiman Long <longman@redhat.com>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    
    Fix typo in patch subject line, and prune a comment detailing how
    the code used to work.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c9d04e1c3ed58f60592329459d9ca7789442ff7
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Dec 4 15:35:53 2019 +0100

    net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup
    
    commit 6c8991f41546c3c472503dff1ea9daaddf9331c2 upstream.
    
    ipv6_stub uses the ip6_dst_lookup function to allow other modules to
    perform IPv6 lookups. However, this function skips the XFRM layer
    entirely.
    
    All users of ipv6_stub->ip6_dst_lookup use ip_route_output_flow (via the
    ip_route_output_key and ip_route_output helpers) for their IPv4 lookups,
    which calls xfrm_lookup_route(). This patch fixes this inconsistent
    behavior by switching the stub to ip6_dst_lookup_flow, which also calls
    xfrm_lookup_route().
    
    This requires some changes in all the callers, as these two functions
    take different arguments and have different return types.
    
    Fixes: 5f81bd2e5d80 ("ipv6: export a stub for IPv6 symbols used by vxlan")
    Reported-by: Xiumei Mu <xmu@redhat.com>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.4:
     - Drop changes in lwt_bpf.c, mlx5, and rxe
     - Adjust filename, context, indentation]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be901a0e5550a481c77578e9500f3f8d52723d6e
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Dec 4 15:35:52 2019 +0100

    net: ipv6: add net argument to ip6_dst_lookup_flow
    
    commit c4e85f73afb6384123e5ef1bba3315b2e3ad031e upstream.
    
    This will be used in the conversion of ipv6_stub to ip6_dst_lookup_flow,
    as some modules currently pass a net argument without a socket to
    ip6_dst_lookup. This is equivalent to commit 343d60aada5a ("ipv6: change
    ipv6_stub_impl.ipv6_dst_lookup to take net argument").
    
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 4.4: adjust context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3f8a70a95fa68dbe6af52f81d06888efc290dd7
Author: Shijie Luo <luoshijie1@huawei.com>
Date:   Mon Feb 10 20:17:52 2020 -0500

    ext4: add cond_resched() to ext4_protect_reserved_inode
    
    commit af133ade9a40794a37104ecbcc2827c0ea373a3c upstream.
    
    When journal size is set too big by "mkfs.ext4 -J size=", or when
    we mount a crafted image to make journal inode->i_size too big,
    the loop, "while (i < num)", holds cpu too long. This could cause
    soft lockup.
    
    [  529.357541] Call trace:
    [  529.357551]  dump_backtrace+0x0/0x198
    [  529.357555]  show_stack+0x24/0x30
    [  529.357562]  dump_stack+0xa4/0xcc
    [  529.357568]  watchdog_timer_fn+0x300/0x3e8
    [  529.357574]  __hrtimer_run_queues+0x114/0x358
    [  529.357576]  hrtimer_interrupt+0x104/0x2d8
    [  529.357580]  arch_timer_handler_virt+0x38/0x58
    [  529.357584]  handle_percpu_devid_irq+0x90/0x248
    [  529.357588]  generic_handle_irq+0x34/0x50
    [  529.357590]  __handle_domain_irq+0x68/0xc0
    [  529.357593]  gic_handle_irq+0x6c/0x150
    [  529.357595]  el1_irq+0xb8/0x140
    [  529.357599]  __ll_sc_atomic_add_return_acquire+0x14/0x20
    [  529.357668]  ext4_map_blocks+0x64/0x5c0 [ext4]
    [  529.357693]  ext4_setup_system_zone+0x330/0x458 [ext4]
    [  529.357717]  ext4_fill_super+0x2170/0x2ba8 [ext4]
    [  529.357722]  mount_bdev+0x1a8/0x1e8
    [  529.357746]  ext4_mount+0x44/0x58 [ext4]
    [  529.357748]  mount_fs+0x50/0x170
    [  529.357752]  vfs_kern_mount.part.9+0x54/0x188
    [  529.357755]  do_mount+0x5ac/0xd78
    [  529.357758]  ksys_mount+0x9c/0x118
    [  529.357760]  __arm64_sys_mount+0x28/0x38
    [  529.357764]  el0_svc_common+0x78/0x130
    [  529.357766]  el0_svc_handler+0x38/0x78
    [  529.357769]  el0_svc+0x8/0xc
    [  541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674]
    
    Link: https://lore.kernel.org/r/20200211011752.29242-1-luoshijie1@huawei.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Shijie Luo <luoshijie1@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d48539bf92c72c74251ebc326564bc8e5bee7de8
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Sep 26 10:15:25 2019 -0700

    binfmt_elf: Do not move brk for INTERP-less ET_EXEC
    
    commit 7be3cb019db1cbd5fd5ffe6d64a23fefa4b6f229 upstream.
    
    When brk was moved for binaries without an interpreter, it should have
    been limited to ET_DYN only. In other words, the special case was an
    ET_DYN that lacks an INTERP, not just an executable that lacks INTERP.
    The bug manifested for giant static executables, where the brk would end
    up in the middle of the text area on 32-bit architectures.
    
    Reported-and-tested-by: Richard Kojedzinszky <richard@kojedz.in>
    Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5956537779b0501934381a3286449ee9d8a09696
Author: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date:   Fri Feb 26 19:18:22 2016 +0100

    phy: micrel: Ensure interrupts are reenabled on resume
    
    [ Upstream commit f5aba91d7f186cba84af966a741a0346de603cd4 ]
    
    At least on ksz8081, when getting back from power down, interrupts are
    disabled. ensure they are reenabled if they were previously enabled.
    
    This fixes resuming which is failing on the xplained boards from atmel
    since 321beec5047a (net: phy: Use interrupts when available in NOLINK
    state)
    
    Fixes: 321beec5047a (net: phy: Use interrupts when available in NOLINK state)
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0ff8cd6ff26cf4e1f51e2648948ae86b63f61ac
Author: Ivan Delalande <colona@arista.com>
Date:   Thu May 7 18:35:53 2020 -0700

    scripts/decodecode: fix trapping instruction formatting
    
    commit e08df079b23e2e982df15aa340bfbaf50f297504 upstream.
    
    If the trapping instruction contains a ':', for a memory access through
    segment registers for example, the sed substitution will insert the '*'
    marker in the middle of the instruction instead of the line address:
    
            2b:   65 48 0f c7 0f          cmpxchg16b %gs:*(%rdi)          <-- trapping instruction
    
    I started to think I had forgotten some quirk of the assembly syntax
    before noticing that it was actually coming from the script.  Fix it to
    add the address marker at the right place for these instructions:
    
            28:   49 8b 06                mov    (%r14),%rax
            2b:*  65 48 0f c7 0f          cmpxchg16b %gs:(%rdi)           <-- trapping instruction
            30:   0f 94 c0                sete   %al
    
    Fixes: 18ff44b189e2 ("scripts/decodecode: make faulting insn ptr more robust")
    Signed-off-by: Ivan Delalande <colona@arista.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/20200419223653.GA31248@visor
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b0aa0499332519297657c3e130957eaf7a7b530
Author: George Spelvin <lkml@sdf.org>
Date:   Sun Mar 8 09:44:59 2020 -0400

    batman-adv: fix batadv_nc_random_weight_tq
    
    commit fd0c42c4dea54335967c5a86f15fc064235a2797 upstream.
    
    and change to pseudorandom numbers, as this is a traffic dithering
    operation that doesn't need crypto-grade.
    
    The previous code operated in 4 steps:
    
    1. Generate a random byte 0 <= rand_tq <= 255
    2. Multiply it by BATADV_TQ_MAX_VALUE - tq
    3. Divide by 255 (= BATADV_TQ_MAX_VALUE)
    4. Return BATADV_TQ_MAX_VALUE - rand_tq
    
    This would apperar to scale (BATADV_TQ_MAX_VALUE - tq) by a random
    value between 0/255 and 255/255.
    
    But!  The intermediate value between steps 3 and 4 is stored in a u8
    variable.  So it's truncated, and most of the time, is less than 255, after
    which the division produces 0.  Specifically, if tq is odd, the product is
    always even, and can never be 255.  If tq is even, there's exactly one
    random byte value that will produce a product byte of 255.
    
    Thus, the return value is 255 (511/512 of the time) or 254 (1/512
    of the time).
    
    If we assume that the truncation is a bug, and the code is meant to scale
    the input, a simpler way of looking at it is that it's returning a random
    value between tq and BATADV_TQ_MAX_VALUE, inclusive.
    
    Well, we have an optimized function for doing just that.
    
    Fixes: 3c12de9a5c75 ("batman-adv: network coding - code and transmit packets if possible")
    Signed-off-by: George Spelvin <lkml@sdf.org>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9764baaebbe9b8be63b8b32df0383b0af3941a8
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Apr 15 16:03:04 2020 +0200

    USB: serial: garmin_gps: add sanity checking for data length
    
    commit e9b3c610a05c1cdf8e959a6d89c38807ff758ee6 upstream.
    
    We must not process packets shorter than a packet ID
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-and-tested-by: syzbot+d29e9263e13ce0b9f4fd@syzkaller.appspotmail.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2ad91a8084345093e6a9af7a6a235f25772ec6d
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Apr 29 17:52:18 2020 +0200

    USB: uas: add quirk for LaCie 2Big Quadra
    
    commit 9f04db234af691007bb785342a06abab5fb34474 upstream.
    
    This device needs US_FL_NO_REPORT_OPCODES to avoid going
    through prolonged error handling on enumeration.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reported-by: Julian Groß <julian.g@posteo.de>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200429155218.7308-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e61d5650ded7718156ee2e33dc3c54075fdfc44e
Author: Alex Estrin <alex.estrin@intel.com>
Date:   Tue Sep 26 06:06:22 2017 -0700

    Revert "IB/ipoib: Update broadcast object if PKey value was changed in index 0"
    
    commit 612601d0013f03de9dc134809f242ba6da9ca252 upstream.
    
    commit 9a9b8112699d will cause core to fail UD QP from being destroyed
    on ipoib unload, therefore cause resources leakage.
    On pkey change event above patch modifies mgid before calling underlying
    driver to detach it from QP. Drivers' detach_mcast() will fail to find
    modified mgid it was never given to attach in a first place.
    Core qp->usecnt will never go down, so ib_destroy_qp() will fail.
    
    IPoIB driver actually does take care of new broadcast mgid based on new
    pkey by destroying an old mcast object in ipoib_mcast_dev_flush())
    ....
            if (priv->broadcast) {
                    rb_erase(&priv->broadcast->rb_node, &priv->multicast_tree);
                    list_add_tail(&priv->broadcast->list, &remove_list);
                    priv->broadcast = NULL;
            }
    ...
    
    then in restarted ipoib_macst_join_task() creating a new broadcast mcast
    object, sending join request and on completion tells the driver to attach
    to reinitialized QP:
    ...
    if (!priv->broadcast) {
    ...
            broadcast = ipoib_mcast_alloc(dev, 0);
    ...
            memcpy(broadcast->mcmember.mgid.raw, priv->dev->broadcast + 4,
                   sizeof (union ib_gid));
            priv->broadcast = broadcast;
    ...
    
    Fixes: 9a9b8112699d ("IB/ipoib: Update broadcast object if PKey value was changed in index 0")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Alex Estrin <alex.estrin@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Reviewed-by: Feras Daoud <ferasda@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42a7e784184cdddd80fb7b8be5e941eb44cbe57e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Jul 9 16:35:34 2018 +0300

    x86/apm: Don't access __preempt_count with zeroed fs
    
    commit 6f6060a5c9cc76fdbc22748264e6aa3779ec2427 upstream.
    
    APM_DO_POP_SEGS does not restore fs/gs which were zeroed by
    APM_DO_ZERO_SEGS. Trying to access __preempt_count with
    zeroed fs doesn't really work.
    
    Move the ibrs call outside the APM_DO_SAVE_SEGS/APM_DO_RESTORE_SEGS
    invocations so that fs is actually restored before calling
    preempt_enable().
    
    Fixes the following sort of oopses:
    [    0.313581] general protection fault: 0000 [#1] PREEMPT SMP
    [    0.313803] Modules linked in:
    [    0.314040] CPU: 0 PID: 268 Comm: kapmd Not tainted 4.16.0-rc1-triton-bisect-00090-gdd84441a7971 #19
    [    0.316161] EIP: __apm_bios_call_simple+0xc8/0x170
    [    0.316161] EFLAGS: 00210016 CPU: 0
    [    0.316161] EAX: 00000102 EBX: 00000000 ECX: 00000102 EDX: 00000000
    [    0.316161] ESI: 0000530e EDI: dea95f64 EBP: dea95f18 ESP: dea95ef0
    [    0.316161]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
    [    0.316161] CR0: 80050033 CR2: 00000000 CR3: 015d3000 CR4: 000006d0
    [    0.316161] Call Trace:
    [    0.316161]  ? cpumask_weight.constprop.15+0x20/0x20
    [    0.316161]  on_cpu0+0x44/0x70
    [    0.316161]  apm+0x54e/0x720
    [    0.316161]  ? __switch_to_asm+0x26/0x40
    [    0.316161]  ? __schedule+0x17d/0x590
    [    0.316161]  kthread+0xc0/0xf0
    [    0.316161]  ? proc_apm_show+0x150/0x150
    [    0.316161]  ? kthread_create_worker_on_cpu+0x20/0x20
    [    0.316161]  ret_from_fork+0x2e/0x38
    [    0.316161] Code: da 8e c2 8e e2 8e ea 57 55 2e ff 1d e0 bb 5d b1 0f 92 c3 5d 5f 07 1f 89 47 0c 90 8d b4 26 00 00 00 00 90 8d b4 26 00 00 00 00 90 <64> ff 0d 84 16 5c b1 74 7f 8b 45 dc 8e e0 8b 45 d8 8e e8 8b 45
    [    0.316161] EIP: __apm_bios_call_simple+0xc8/0x170 SS:ESP: 0068:dea95ef0
    [    0.316161] ---[ end trace 656253db2deaa12c ]---
    
    Fixes: dd84441a7971 ("x86/speculation: Use IBRS if available before calling into firmware")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Cc:  David Woodhouse <dwmw@amazon.co.uk>
    Cc:  "H. Peter Anvin" <hpa@zytor.com>
    Cc:  x86@kernel.org
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lkml.kernel.org/r/20180709133534.5963-1-ville.syrjala@linux.intel.com
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93567229892d46d0fb5fc5b9c977fb64b3465fdd
Author: Kees Cook <keescook@chromium.org>
Date:   Tue May 14 15:43:57 2019 -0700

    binfmt_elf: move brk out of mmap when doing direct loader exec
    
    commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream.
    
    Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
    made changes in the rare case when the ELF loader was directly invoked
    (e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
    the loader), by moving into the mmap region to avoid both ET_EXEC and
    PIE binaries.  This had the effect of also moving the brk region into
    mmap, which could lead to the stack and brk being arbitrarily close to
    each other.  An unlucky process wouldn't get its requested stack size
    and stack allocations could end up scribbling on the heap.
    
    This is illustrated here.  In the case of using the loader directly, brk
    (so helpfully identified as "[heap]") is allocated with the _loader_ not
    the binary.  For example, with ASLR entirely disabled, you can see this
    more clearly:
    
    $ /bin/cat /proc/self/maps
    555555554000-55555555c000 r-xp 00000000 ... /bin/cat
    55555575b000-55555575c000 r--p 00007000 ... /bin/cat
    55555575c000-55555575d000 rw-p 00008000 ... /bin/cat
    55555575d000-55555577e000 rw-p 00000000 ... [heap]
    ...
    7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
    7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
    7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
    7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
    7ffff7ffe000-7ffff7fff000 rw-p 00000000 ...
    7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
    
    $ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps
    ...
    7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat
    7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat
    7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat
    7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat
    7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so
    7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ...
    7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
    7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
    7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
    7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
    7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap]
    7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
    
    The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since
    nothing is there in the direct loader case (and ET_EXEC is still far
    away at 0x400000).  Anything that ran before should still work (i.e.
    the ultimately-launched binary already had the brk very far from its
    text, so this should be no different from a COMPAT_BRK standpoint).  The
    only risk I see here is that if someone started to suddenly depend on
    the entire memory space lower than the mmap region being available when
    launching binaries via a direct loader execs which seems highly
    unlikely, I'd hope: this would mean a binary would _not_ work when
    exec()ed normally.
    
    (Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION
    when randomization is turned on.)
    
    Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast
    Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com
    Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Ali Saidi <alisaidi@amazon.com>
    Cc: Ali Saidi <alisaidi@amazon.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jann Horn <jannh@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48a238024893ba8154446fedec2909ec6e971bf6
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Tue Aug 28 13:40:51 2018 +0200

    ipv6: fix cleanup ordering for ip6_mr failure
    
    commit afe49de44c27a89e8e9631c44b5ffadf6ace65e2 upstream.
    
    Commit 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
    moved the cleanup label for ipmr_fail, but should have changed the
    contents of the cleanup labels as well. Now we can end up cleaning up
    icmpv6 even though it hasn't been initialized (jump to icmp_fail or
    ipmr_fail).
    
    Simply undo things in the reverse order of their initialization.
    
    Example of panic (triggered by faking a failure of icmpv6_init):
    
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
        [...]
        RIP: 0010:__list_del_entry_valid+0x79/0x160
        [...]
        Call Trace:
         ? lock_release+0x8a0/0x8a0
         unregister_pernet_operations+0xd4/0x560
         ? ops_free_list+0x480/0x480
         ? down_write+0x91/0x130
         ? unregister_pernet_subsys+0x15/0x30
         ? down_read+0x1b0/0x1b0
         ? up_read+0x110/0x110
         ? kmem_cache_create_usercopy+0x1b4/0x240
         unregister_pernet_subsys+0x1d/0x30
         icmpv6_cleanup+0x1d/0x30
         inet6_init+0x1b5/0x23f
    
    Fixes: 15e668070a64 ("ipv6: reorder icmpv6_init() and ip6_mr_init()")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4537e64a916783c508fda01c5f0f44bbd342adae
Author: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date:   Mon Jun 18 10:01:05 2018 -0700

    enic: do not overwrite error code
    
    commit 56f772279a762984f6e9ebbf24a7c829faba5712 upstream.
    
    In failure path, we overwrite err to what vnic_rq_disable() returns. In
    case it returns 0, enic_open() returns success in case of error.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Fixes: e8588e268509 ("enic: enable rq before updating rq descriptors")
    Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3e3e34f212aad219d03cdf1b6f8a068753f661f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Jan 22 13:24:05 2017 +0100

    Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"
    
    commit fd25ea29093e275195d0ae8b2573021a1c98959f upstream.
    
    Revert commit 6276e53fa8c0 (ACPI / video: Add force_native quirk for
    HP Pavilion dv6).
    
    In the commit message for the quirk this revert removes I wrote:
    
    "Note that there are quite a few HP Pavilion dv6 variants, some
    woth ATI and some with NVIDIA hybrid gfx, both seem to need this
    quirk to have working backlight control. There are also some versions
    with only Intel integrated gfx, these may not need this quirk, but it
    should not hurt there."
    
    Unfortunately that seems wrong, I've already received 2 reports of
    this commit causing regressions on some dv6 variants (at least one
    of which actually has a nvidia GPU). So it seems that HP has made a
    mess here by using the same model-name both in marketing and in the
    DMI data for many different variants. Some of which need
    acpi_backlight=native for functional backlight control (as the
    quirk this commit reverts was doing), where as others are broken by
    it. So lets get back to the old sitation so as to avoid regressing
    on models which used to work without any kernel cmdline arguments
    before.
    
    Fixes: 6276e53fa8c0 (ACPI / video: Add force_native quirk for HP Pavilion dv6)
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9aa2c8807b694ffa154cf421227b56723558059d
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Apr 25 15:19:51 2020 -0700

    sch_choke: avoid potential panic in choke_reset()
    
    [ Upstream commit 8738c85c72b3108c9b9a369a39868ba5f8e10ae0 ]
    
    If choke_init() could not allocate q->tab, we would crash later
    in choke_reset().
    
    BUG: KASAN: null-ptr-deref in memset include/linux/string.h:366 [inline]
    BUG: KASAN: null-ptr-deref in choke_reset+0x208/0x340 net/sched/sch_choke.c:326
    Write of size 8 at addr 0000000000000000 by task syz-executor822/7022
    
    CPU: 1 PID: 7022 Comm: syz-executor822 Not tainted 5.7.0-rc1-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x188/0x20d lib/dump_stack.c:118
     __kasan_report.cold+0x5/0x4d mm/kasan/report.c:515
     kasan_report+0x33/0x50 mm/kasan/common.c:625
     check_memory_region_inline mm/kasan/generic.c:187 [inline]
     check_memory_region+0x141/0x190 mm/kasan/generic.c:193
     memset+0x20/0x40 mm/kasan/common.c:85
     memset include/linux/string.h:366 [inline]
     choke_reset+0x208/0x340 net/sched/sch_choke.c:326
     qdisc_reset+0x6b/0x520 net/sched/sch_generic.c:910
     dev_deactivate_queue.constprop.0+0x13c/0x240 net/sched/sch_generic.c:1138
     netdev_for_each_tx_queue include/linux/netdevice.h:2197 [inline]
     dev_deactivate_many+0xe2/0xba0 net/sched/sch_generic.c:1195
     dev_deactivate+0xf8/0x1c0 net/sched/sch_generic.c:1233
     qdisc_graft+0xd25/0x1120 net/sched/sch_api.c:1051
     tc_modify_qdisc+0xbab/0x1a00 net/sched/sch_api.c:1670
     rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5454
     netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469
     netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
     netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329
     netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918
     sock_sendmsg_nosec net/socket.c:652 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:672
     ____sys_sendmsg+0x6bf/0x7e0 net/socket.c:2362
     ___sys_sendmsg+0x100/0x170 net/socket.c:2416
     __sys_sendmsg+0xec/0x1b0 net/socket.c:2449
     do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
    
    Fixes: 77e62da6e60c ("sch_choke: drop all packets in queue during reset")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 116555b32d992998e574bebd3792fa67a5bfcff0
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Apr 26 18:19:07 2020 -0700

    sch_sfq: validate silly quantum values
    
    [ Upstream commit df4953e4e997e273501339f607b77953772e3559 ]
    
    syzbot managed to set up sfq so that q->scaled_quantum was zero,
    triggering an infinite loop in sfq_dequeue()
    
    More generally, we must only accept quantum between 1 and 2^18 - 7,
    meaning scaled_quantum must be in [1, 0x7FFF] range.
    
    Otherwise, we also could have a loop in sfq_dequeue()
    if scaled_quantum happens to be 0x8000, since slot->allot
    could indefinitely switch between 0 and 0x8000.
    
    Fixes: eeaeb068f139 ("sch_sfq: allow big packets and be fair")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+0251e883fe39e7a0cb0a@syzkaller.appspotmail.com
    Cc: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96a1e05f7b21e50c887336ac6ae249bdf62dfaed
Author: Tariq Toukan <tariqt@mellanox.com>
Date:   Mon May 4 11:36:02 2020 +0300

    net/mlx4_core: Fix use of ENOSPC around mlx4_counter_alloc()
    
    [ Upstream commit 40e473071dbad04316ddc3613c3a3d1c75458299 ]
    
    When ENOSPC is set the idx is still valid and gets set to the global
    MLX4_SINK_COUNTER_INDEX.  However gcc's static analysis cannot tell that
    ENOSPC is impossible from mlx4_cmd_imm() and gives this warning:
    
    drivers/net/ethernet/mellanox/mlx4/main.c:2552:28: warning: 'idx' may be
    used uninitialized in this function [-Wmaybe-uninitialized]
     2552 |    priv->def_counter[port] = idx;
    
    Also, when ENOSPC is returned mlx4_allocate_default_counters should not
    fail.
    
    Fixes: 6de5f7f6a1fa ("net/mlx4_core: Allocate default counter per port")
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 405a8cc9b4ed889990d014538607a9c5752b06d2
Author: Julia Lawall <Julia.Lawall@inria.fr>
Date:   Thu Apr 30 21:51:32 2020 +0200

    dp83640: reverse arguments to list_add_tail
    
    [ Upstream commit 865308373ed49c9fb05720d14cbf1315349b32a9 ]
    
    In this code, it appears that phyter_clocks is a list head, based on
    the previous list_for_each, and that clock->list is intended to be a
    list element, given that it has just been initialized in
    dp83640_clock_init.  Accordingly, switch the arguments to
    list_add_tail, which takes the list head as the second argument.
    
    Fixes: cb646e2b02b27 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
    Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bdfb137c352adaca826afb0948d92285db2fa28
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 12 10:29:52 2020 +0200

    Revert "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
    
    This reverts commit 0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd which was
    commit d5c3d84657db57bd23ecd58b97f1c99dd42a7b80 upstream.
    
    Guillaume reports that this patch breaks booting on
    at91-sama5d4_xplained, so revert it for now.
    
    Reported-by: "kernelci.org bot" <bot@kernelci.org>
    Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fffb8dbdae34582d81fc1f5d996f43f066b2367
Author: Matt Jolly <Kangie@footclan.ninja>
Date:   Sun May 3 01:03:47 2020 +1000

    USB: serial: qcserial: Add DW5816e support
    
    commit 78d6de3cfbd342918d31cf68d0d2eda401338aef upstream.
    
    Add support for Dell Wireless 5816e to drivers/usb/serial/qcserial.c
    
    Signed-off-by: Matt Jolly <Kangie@footclan.ninja>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>