commit cb49f0e441ce7db63ef67ccfa9d9562c22f5d6c3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Oct 25 11:54:26 2023 +0200

    Linux 5.10.199
    
    Link: https://lore.kernel.org/r/20231023104817.691299567@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Link: https://lore.kernel.org/r/20231024083306.700855687@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Slade Watkins <srw@sladewatkins.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657a3ca8236c45a3b5358985c807991e0697dabf
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Sep 15 19:20:41 2023 +0800

    xfrm6: fix inet6_dev refcount underflow problem
    
    [ Upstream commit cc9b364bb1d58d3dae270c7a931a8cc717dc2b3b ]
    
    There are race conditions that may lead to inet6_dev refcount underflow
    in xfrm6_dst_destroy() and rt6_uncached_list_flush_dev().
    
    One of the refcount underflow bugs is shown below:
            (cpu 1)                 |       (cpu 2)
    xfrm6_dst_destroy()             |
      ...                           |
      in6_dev_put()                 |
                                    |  rt6_uncached_list_flush_dev()
      ...                           |    ...
                                    |    in6_dev_put()
      rt6_uncached_list_del()       |    ...
      ...                           |
    
    xfrm6_dst_destroy() calls rt6_uncached_list_del() after in6_dev_put(),
    so rt6_uncached_list_flush_dev() has a chance to call in6_dev_put()
    again for the same inet6_dev.
    
    Fix it by moving in6_dev_put() after rt6_uncached_list_del() in
    xfrm6_dst_destroy().
    
    Fixes: 510c321b5571 ("xfrm: reuse uncached_list to track xdsts")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d5680755bcef70b484602f16de40fcb324cb784
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Oct 11 09:31:44 2023 -0700

    Bluetooth: hci_sock: Correctly bounds check and pad HCI_MON_NEW_INDEX name
    
    commit cb3871b1cd135a6662b732fbc6b3db4afcdb4a64 upstream.
    
    The code pattern of memcpy(dst, src, strlen(src)) is almost always
    wrong. In this case it is wrong because it leaves memory uninitialized
    if it is less than sizeof(ni->name), and overflows ni->name when longer.
    
    Normally strtomem_pad() could be used here, but since ni->name is a
    trailing array in struct hci_mon_new_index, compilers that don't support
    -fstrict-flex-arrays=3 can't tell how large this array is via
    __builtin_object_size(). Instead, open-code the helper and use sizeof()
    since it will work correctly.
    
    Additionally mark ni->name as __nonstring since it appears to not be a
    %NUL terminated C string.
    
    Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Cc: Edward AD <twuufnxlz@gmail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: linux-bluetooth@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Fixes: 18f547f3fc07 ("Bluetooth: hci_sock: fix slab oob read in create_monitor_event")
    Link: https://lore.kernel.org/lkml/202310110908.F2639D3276@keescook/
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b423509bc99c7c7a7e31d0daa858bca9c45e5f54
Author: Edward AD <twuufnxlz@gmail.com>
Date:   Tue Oct 10 13:36:57 2023 +0800

    Bluetooth: hci_sock: fix slab oob read in create_monitor_event
    
    commit 18f547f3fc074500ab5d419cf482240324e73a7e upstream.
    
    When accessing hdev->name, the actual string length should prevail
    
    Reported-by: syzbot+c90849c50ed209d77689@syzkaller.appspotmail.com
    Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings")
    Signed-off-by: Edward AD <twuufnxlz@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 653c808023cd2af518eba4f39207dde12ee8af07
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Sep 13 09:04:29 2023 +0300

    phy: mapphone-mdm6600: Fix pinctrl_pm handling for sleep pins
    
    [ Upstream commit 3b384cc74b00b5ac21d18e4c1efc3c1da5300971 ]
    
    Looks like the driver sleep pins configuration is unusable. Adding the
    sleep pins causes the usb phy to not respond. We need to use the default
    pins in probe, and only set sleep pins at phy_mdm6600_device_power_off().
    
    As the modem can also be booted to a serial port mode for firmware
    flashing, let's make the pin changes limited to probe and remove. For
    probe, we get the default pins automatically. We only need to set the
    sleep pins in phy_mdm6600_device_power_off() to prevent the modem from
    waking up because the gpio line glitches.
    
    If it turns out that we need a separate state for phy_mdm6600_power_on()
    and phy_mdm6600_power_off(), we can use the pinctrl idle state.
    
    Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Sebastian Reichel <sre@kernel.org>
    Fixes: 2ad2af081622 ("phy: mapphone-mdm6600: Improve phy related runtime PM calls")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Link: https://lore.kernel.org/r/20230913060433.48373-3-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9c20d3078ccf2399fe80291fcf1e39d0b665538
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Sep 13 09:04:28 2023 +0300

    phy: mapphone-mdm6600: Fix runtime PM for remove
    
    [ Upstream commit b99e0ba9633af51638e5ee1668da2e33620c134f ]
    
    Otherwise we will get an underflow on remove.
    
    Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Sebastian Reichel <sre@kernel.org>
    Fixes: f7f50b2a7b05 ("phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Link: https://lore.kernel.org/r/20230913060433.48373-2-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f42634685ee5fac1387b74d0b9f0a200ed5441a1
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Sep 13 09:04:27 2023 +0300

    phy: mapphone-mdm6600: Fix runtime disable on probe
    
    [ Upstream commit 719606154c7033c068a5d4c1dc5f9163b814b3c8 ]
    
    Commit d644e0d79829 ("phy: mapphone-mdm6600: Fix PM error handling in
    phy_mdm6600_probe") caused a regression where we now unconditionally
    disable runtime PM at the end of the probe while it is only needed on
    errors.
    
    Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Miaoqian Lin <linmq006@gmail.com>
    Cc: Pavel Machek <pavel@ucw.cz>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Fixes: d644e0d79829 ("phy: mapphone-mdm6600: Fix PM error handling in phy_mdm6600_probe")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20230913060433.48373-1-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 05e06fb6a6423f1ab59210c1616abb8272e13e53
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Oct 5 17:00:24 2023 +0300

    ASoC: pxa: fix a memory leak in probe()
    
    [ Upstream commit aa6464edbd51af4a2f8db43df866a7642b244b5f ]
    
    Free the "priv" pointer before returning the error code.
    
    Fixes: 90eb6b59d311 ("ASoC: pxa-ssp: add support for an external clock in devicetree")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/84ac2313-1420-471a-b2cb-3269a2e12a7c@moroto.mountain
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e29dadf265d28dfc7a0ae3a1069678b642ee2e6
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Wed Oct 18 11:00:17 2023 +0200

    gpio: vf610: set value before the direction to avoid a glitch
    
    commit fc363413ef8ea842ae7a99e3caf5465dafdd3a49 upstream.
    
    We found a glitch when configuring the pad as output high. To avoid this
    glitch, move the data value setting before direction config in the
    function vf610_gpio_direction_output().
    
    Fixes: 659d8a62311f ("gpio: vf610: add imx7ulp support")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    [Bartosz: tweak the commit message]
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c3a72d4ae243a63f0208a5e669e63d60af55614
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Oct 17 11:07:25 2023 +0200

    platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events
    
    commit 235985d1763f7aba92c1c64e5f5aaec26c2c9b18 upstream.
    
    Newer Asus laptops send the following new WMI event codes when some
    of the F1 - F12 "media" hotkeys are pressed:
    
    0x2a Screen Capture
    0x2b PrintScreen
    0x2c CapsLock
    
    Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
    are mapped on other laptops.
    
    PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
    map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
    messages.
    
    Reported-by: James John <me@donjajo.com>
    Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
    Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fece0081b64bbbdac90c495c4d7e5a2c385fb66
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Oct 17 11:07:23 2023 +0200

    platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e
    
    commit f37cc2fc277b371fc491890afb7d8a26e36bb3a1 upstream.
    
    Older Asus laptops change the backlight level themselves and then send
    WMI events with different codes for different backlight levels.
    
    The asus-wmi.c code maps the entire range of codes reported on
    brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:
    
    define NOTIFY_BRNUP_MIN                0x11
    define NOTIFY_BRNUP_MAX                0x1f
    define NOTIFY_BRNDOWN_MIN              0x20
    define NOTIFY_BRNDOWN_MAX              0x2e
    
            if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
                    code = ASUS_WMI_BRN_UP;
            else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
                    code = ASUS_WMI_BRN_DOWN;
    
    Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
    aka 0x20 - 0x2e events were mapped to 0x20.
    
    This mapping is causing issues on new laptop models which actually
    send 0x2b events for printscreen presses and 0x2c events for
    capslock presses, which get translated into spurious brightness-down
    presses.
    
    The plan is disable the 0x11-0x2e special mapping on laptops
    where asus-wmi does not register a backlight-device to avoid
    the spurious brightness-down keypresses. New laptops always send
    0x2e for brightness-down presses, change the special internal
    ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
    preparation for fixing the spurious brightness-down presses.
    
    This change does not have any functional impact since all
    of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
    then checked against the keymap code and the new 0x2e
    value is still in the 0x20 - 0x2e range.
    
    Reported-by: James John <me@donjajo.com>
    Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
    Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231017090725.38163-2-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be044840e8e467de69d8361d7145f0f992b295c
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Oct 17 15:37:29 2023 +0200

    s390/pci: fix iommu bitmap allocation
    
    commit c1ae1c59c8c6e0b66a718308c623e0cb394dab6b upstream.
    
    Since the fixed commits both zdev->iommu_bitmap and zdev->lazy_bitmap
    are allocated as vzalloc(zdev->iommu_pages / 8). The problem is that
    zdev->iommu_bitmap is a pointer to unsigned long but the above only
    yields an allocation that is a multiple of sizeof(unsigned long) which
    is 8 on s390x if the number of IOMMU pages is a multiple of 64.
    This in turn is the case only if the effective IOMMU aperture is
    a multiple of 64 * 4K = 256K. This is usually the case and so didn't
    cause visible issues since both the virt_to_phys(high_memory) reduced
    limit and hardware limits use nice numbers.
    
    Under KVM, and in particular with QEMU limiting the IOMMU aperture to
    the vfio DMA limit (default 65535), it is possible for the reported
    aperture not to be a multiple of 256K however. In this case we end up
    with an iommu_bitmap whose allocation is not a multiple of
    8 causing bitmap operations to access it out of bounds.
    
    Sadly we can't just fix this in the obvious way and use bitmap_zalloc()
    because for large RAM systems (tested on 8 TiB) the zdev->iommu_bitmap
    grows too large for kmalloc(). So add our own bitmap_vzalloc() wrapper.
    This might be a candidate for common code, but this area of code will
    be replaced by the upcoming conversion to use the common code DMA API on
    s390 so just add a local routine.
    
    Fixes: 224593215525 ("s390/pci: use virtual memory for iommu bitmap")
    Fixes: 13954fd6913a ("s390/pci_dma: improve lazy flush for unmap")
    Cc: stable@vger.kernel.org
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 487a8e24643a0effb2ba19cad3227fc75dc3c4b7
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Oct 18 13:56:54 2023 +0200

    perf: Disallow mis-matched inherited group reads
    
    commit 32671e3799ca2e4590773fd0e63aaa4229e50c06 upstream.
    
    Because group consistency is non-atomic between parent (filedesc) and children
    (inherited) events, it is possible for PERF_FORMAT_GROUP read() to try and sum
    non-matching counter groups -- with non-sensical results.
    
    Add group_generation to distinguish the case where a parent group removes and
    adds an event and thus has the same number, but a different configuration of
    events as inherited groups.
    
    This became a problem when commit fa8c269353d5 ("perf/core: Invert
    perf_read_group() loops") flipped the order of child_list and sibling_list.
    Previously it would iterate the group (sibling_list) first, and for each
    sibling traverse the child_list. In this order, only the group composition of
    the parent is relevant. By flipping the order the group composition of the
    child (inherited) events becomes an issue and the mis-match in group
    composition becomes evident.
    
    That said; even prior to this commit, while reading of a group that is not
    equally inherited was not broken, it still made no sense.
    
    (Ab)use ECHILD as error return to indicate issues with child process group
    composition.
    
    Fixes: fa8c269353d5 ("perf/core: Invert perf_read_group() loops")
    Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20231018115654.GK33217@noisy.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 550c70f72a1b00190111c7247319eb94dc5d3dab
Author: Puliang Lu <puliang.lu@fibocom.com>
Date:   Mon Oct 16 15:36:16 2023 +0800

    USB: serial: option: add Fibocom to DELL custom modem FM101R-GL
    
    commit 52480e1f1a259c93d749ba3961af0bffedfe7a7a upstream.
    
    Update the USB serial option driver support for the Fibocom
    FM101R-GL LTE modules as there are actually several different variants.
    
    - VID:PID 413C:8213, FM101R-GL are laptop M.2 cards (with
      MBIM interfaces for Linux)
    
    - VID:PID 413C:8215, FM101R-GL ESIM are laptop M.2 cards (with
      MBIM interface for Linux)
    
    0x8213: mbim, tty
    0x8215: mbim, tty
    
    T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=413c ProdID=8213 Rev= 5.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom FM101-GL Module
    S:  SerialNumber=a3b7cbf0
    C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  3 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=413c ProdID=8215 Rev= 5.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom FM101-GL Module
    S:  SerialNumber=a3b7cbf0
    C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Puliang Lu <puliang.lu@fibocom.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a39ea926ff6da9c026f6a051a98f1cbb830a2b67
Author: Benoît Monin <benoit.monin@gmx.fr>
Date:   Mon Oct 2 17:51:40 2023 +0200

    USB: serial: option: add entry for Sierra EM9191 with new firmware
    
    commit 064f6e2ba9eb59b2c87b866e1e968e79ccedf9dd upstream.
    
    Following a firmware update of the modem, the interface for the AT
    command port changed, so add it back.
    
    T:  Bus=08 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=1199 ProdID=90d3 Rev=00.06
    S:  Manufacturer=Sierra Wireless, Incorporated
    S:  Product=Sierra Wireless EM9191
    S:  SerialNumber=xxxxxxxxxxxxxxxx
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none)
    I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    
    Signed-off-by: Benoît Monin <benoit.monin@gmx.fr>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fb223086de9b51cf94e22fea9b2dfec3cbade51
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Tue Sep 5 09:37:24 2023 +0200

    USB: serial: option: add Telit LE910C4-WWX 0x1035 composition
    
    commit 6a7be48e9bd18d309ba25c223a27790ad1bf0fa3 upstream.
    
    Add support for the following Telit LE910C4-WWX composition:
    
    0x1035: TTY, TTY, ECM
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1035 Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=e1b117c7
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    I:  If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d78d3e0d8462d486217264a78fa46e1190bb86f4
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Mon Jul 31 12:37:58 2023 +0200

    nvme-rdma: do not try to stop unallocated queues
    
    commit 3820c4fdc247b6f0a4162733bdb8ddf8f2e8a1e4 upstream.
    
    Trying to stop a queue which hasn't been allocated will result
    in a warning due to calling mutex_lock() against an uninitialized mutex.
    
     DEBUG_LOCKS_WARN_ON(lock->magic != lock)
     WARNING: CPU: 4 PID: 104150 at kernel/locking/mutex.c:579
    
     Call trace:
      RIP: 0010:__mutex_lock+0x1173/0x14a0
      nvme_rdma_stop_queue+0x1b/0xa0 [nvme_rdma]
      nvme_rdma_teardown_io_queues.part.0+0xb0/0x1d0 [nvme_rdma]
      nvme_rdma_delete_ctrl+0x50/0x100 [nvme_rdma]
      nvme_do_delete_ctrl+0x149/0x158 [nvme_core]
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6238faecf88a68fc26b2a79584d802a00c4ca1ad
Author: Keith Busch <kbusch@kernel.org>
Date:   Thu Oct 12 11:13:51 2023 -0700

    nvme-pci: add BOGUS_NID for Intel 0a54 device
    
    commit 5c3f4066462a5f6cac04d3dd81c9f551fabbc6c7 upstream.
    
    These ones claim cmic and nmic capable, so need special consideration to ignore
    their duplicate identifiers.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217981
    Reported-by: welsh@cassens.com
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9efa38fdca2cfee4a11ec7d55a80e693bf8db4f5
Author: Sunil V L <sunilvl@ventanamicro.com>
Date:   Mon Oct 16 22:39:39 2023 +0530

    ACPI: irq: Fix incorrect return value in acpi_register_gsi()
    
    commit 0c21a18d5d6c6a73d098fb9b4701572370942df9 upstream.
    
    acpi_register_gsi() should return a negative value in case of failure.
    
    Currently, it returns the return value from irq_create_fwspec_mapping().
    However, irq_create_fwspec_mapping() returns 0 for failure. Fix the
    issue by returning -EINVAL if irq_create_fwspec_mapping() returns zero.
    
    Fixes: d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
    Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
    Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
    [ rjw: Rename a new local variable ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9df654268aecd616998aa1526bd072d27b58a7f1
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sun Oct 8 14:20:19 2023 -0400

    pNFS: Fix a hang in nfs4_evict_inode()
    
    commit f63955721a8020e979b99cc417dcb6da3106aa24 upstream.
    
    We are not allowed to call pnfs_mark_matching_lsegs_return() without
    also holding a reference to the layout header, since doing so could lead
    to the reference count going to zero when we call
    pnfs_layout_remove_lseg(). This again can lead to a hang when we get to
    nfs4_evict_inode() and are unable to clear the layout pointer.
    
    pnfs_layout_return_unused_byserver() is guilty of this behaviour, and
    has been seen to trigger the refcount warning prior to a hang.
    
    Fixes: b6d49ecd1081 ("NFSv4: Fix a pNFS layout related use-after-free race when freeing the inode")
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c44e09a89ad20aa09249b83fd2937626550377dc
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Oct 17 17:18:06 2023 +0300

    Revert "pinctrl: avoid unsafe code pattern in find_pinctrl()"
    
    commit 62140a1e4dec4594d5d1e1d353747bf2ef434e8b upstream.
    
    The commit breaks MMC enumeration on the Intel Merrifield
    plaform.
    
    Before:
    [   36.439057] mmc0: SDHCI controller on PCI [0000:00:01.0] using ADMA
    [   36.450924] mmc2: SDHCI controller on PCI [0000:00:01.3] using ADMA
    [   36.459355] mmc1: SDHCI controller on PCI [0000:00:01.2] using ADMA
    [   36.706399] mmc0: new DDR MMC card at address 0001
    [   37.058972] mmc2: new ultra high speed DDR50 SDIO card at address 0001
    [   37.278977] mmcblk0: mmc0:0001 H4G1d 3.64 GiB
    [   37.297300]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
    
    After:
    [   36.436704] mmc2: SDHCI controller on PCI [0000:00:01.3] using ADMA
    [   36.436720] mmc1: SDHCI controller on PCI [0000:00:01.0] using ADMA
    [   36.463685] mmc0: SDHCI controller on PCI [0000:00:01.2] using ADMA
    [   36.720627] mmc1: new DDR MMC card at address 0001
    [   37.068181] mmc2: new ultra high speed DDR50 SDIO card at address 0001
    [   37.279998] mmcblk1: mmc1:0001 H4G1d 3.64 GiB
    [   37.302670]  mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
    
    This reverts commit c153a4edff6ab01370fcac8e46f9c89cca1060c2.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20231017141806.535191-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b26b0b8757c6a058bd7fa97504d3ae4eb054d4df
Author: Avri Altman <avri.altman@wdc.com>
Date:   Wed Sep 27 10:15:00 2023 +0300

    mmc: core: Capture correct oemid-bits for eMMC cards
    
    commit 84ee19bffc9306128cd0f1c650e89767079efeff upstream.
    
    The OEMID is an 8-bit binary number rather than 16-bit as the current code
    parses for. The OEMID occupies bits [111:104] in the CID register, see the
    eMMC spec JESD84-B51 paragraph 7.2.3. It seems that the 16-bit comes from
    the legacy MMC specs (v3.31 and before).
    
    Let's fix the parsing by simply move to use 8-bit instead of 16-bit. This
    means we ignore the impact on some of those old MMC cards that may be out
    there, but on the other hand this shouldn't be a problem as the OEMID seems
    not be an important feature for these cards.
    
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230927071500.1791882-1-avri.altman@wdc.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4771efb068359f0437cf57838ec4d5fdb404aba
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Wed Aug 30 17:39:22 2023 +0800

    mmc: core: sdio: hold retuning if sdio in 1-bit mode
    
    commit 32a9cdb8869dc111a0c96cf8e1762be9684af15b upstream.
    
    tuning only support in 4-bit mode or 8 bit mode, so in 1-bit mode,
    need to hold retuning.
    
    Find this issue when use manual tuning method on imx93. When system
    resume back, SDIO WIFI try to switch back to 4 bit mode, first will
    trigger retuning, and all tuning command failed.
    
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: dfa13ebbe334 ("mmc: host: Add facility to support re-tuning")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230830093922.3095850-1-haibo.chen@nxp.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2312fb7f3b20fe58768f0020eb8c094d15f85c2c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Aug 30 17:00:34 2023 +0200

    mtd: physmap-core: Restore map_rom fallback
    
    commit 6792b7fce610bcd1cf3e07af3607fe7e2c38c1d8 upstream.
    
    When the exact mapping type driver was not available, the old
    physmap_of_core driver fell back to mapping the region as ROM.
    Unfortunately this feature was lost when the DT and pdata cases were
    merged.  Revive this useful feature.
    
    Fixes: 642b1e8dbed7bbbf ("mtd: maps: Merge physmap_of.c into physmap-core.c")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/550e8c8c1da4c4baeb3d71ff79b14a18d4194f9e.1693407371.git.geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a141424f8fe989d8c0e7890cafd3b035d7ac55d
Author: Martin Kurbanov <mmkurbanov@sberdevices.ru>
Date:   Tue Sep 5 17:56:37 2023 +0300

    mtd: spinand: micron: correct bitmask for ecc status
    
    commit 9836a987860e33943945d4b257729a4f94eae576 upstream.
    
    Valid bitmask is 0x70 in the status register.
    
    Fixes: a508e8875e13 ("mtd: spinand: Add initial support for Micron MT29F2G01ABAGD")
    Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru>
    Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230905145637.139068-1-mmkurbanov@sberdevices.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7682dae0a6076a1c3374dea2cef93f85793ed2df
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Mon Jul 17 21:42:20 2023 +0200

    mtd: rawnand: arasan: Ensure program page operations are successful
    
    commit 3a4a893dbb19e229db3b753f0462520b561dee98 upstream.
    
    The NAND core complies with the ONFI specification, which itself
    mentions that after any program or erase operation, a status check
    should be performed to see whether the operation was finished *and*
    successful.
    
    The NAND core offers helpers to finish a page write (sending the
    "PAGE PROG" command, waiting for the NAND chip to be ready again, and
    checking the operation status). But in some cases, advanced controller
    drivers might want to optimize this and craft their own page write
    helper to leverage additional hardware capabilities, thus not always
    using the core facilities.
    
    Some drivers, like this one, do not use the core helper to finish a page
    write because the final cycles are automatically managed by the
    hardware. In this case, the additional care must be taken to manually
    perform the final status check.
    
    Let's read the NAND chip status at the end of the page write helper and
    return -EIO upon error.
    
    Cc: Michal Simek <michal.simek@amd.com>
    Cc: stable@vger.kernel.org
    Fixes: 88ffef1b65cf ("mtd: rawnand: arasan: Support the hardware BCH ECC engine")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Acked-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/linux-mtd/20230717194221.229778-2-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 875d17e4524b1017d4440cb497af7ddc8e394626
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Mon Jul 17 21:42:19 2023 +0200

    mtd: rawnand: marvell: Ensure program page operations are successful
    
    commit 3e01d5254698ea3d18e09d96b974c762328352cd upstream.
    
    The NAND core complies with the ONFI specification, which itself
    mentions that after any program or erase operation, a status check
    should be performed to see whether the operation was finished *and*
    successful.
    
    The NAND core offers helpers to finish a page write (sending the
    "PAGE PROG" command, waiting for the NAND chip to be ready again, and
    checking the operation status). But in some cases, advanced controller
    drivers might want to optimize this and craft their own page write
    helper to leverage additional hardware capabilities, thus not always
    using the core facilities.
    
    Some drivers, like this one, do not use the core helper to finish a page
    write because the final cycles are automatically managed by the
    hardware. In this case, the additional care must be taken to manually
    perform the final status check.
    
    Let's read the NAND chip status at the end of the page write helper and
    return -EIO upon error.
    
    Cc: stable@vger.kernel.org
    Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
    Reported-by: Aviram Dali <aviramd@marvell.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Ravi Chandra Minnikanti <rminnikanti@marvell.com>
    Link: https://lore.kernel.org/linux-mtd/20230717194221.229778-1-miquel.raynal@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6224890ad0b4e85a909349bdc8606dab50d0daf5
Author: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
Date:   Wed Sep 13 12:37:02 2023 +0530

    mtd: rawnand: qcom: Unmap the right resource upon probe failure
    
    commit 5279f4a9eed3ee7d222b76511ea7a22c89e7eefd upstream.
    
    We currently provide the physical address of the DMA region
    rather than the output of dma_map_resource() which is obviously wrong.
    
    Fixes: 7330fc505af4 ("mtd: rawnand: qcom: stop using phys_to_dma()")
    Cc: stable@vger.kernel.org
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20230913070702.12707-1-quic_bibekkum@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f707bc0a55b7d01419cd3ca6506bd574e272f815
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Oct 5 13:59:59 2023 -0700

    Bluetooth: hci_event: Fix using memcmp when comparing keys
    
    [ Upstream commit b541260615f601ae1b5d6d0cc54e790de706303b ]
    
    memcmp is not consider safe to use with cryptographic secrets:
    
     'Do  not  use memcmp() to compare security critical data, such as
     cryptographic secrets, because the required CPU time depends on the
     number of equal bytes.'
    
    While usage of memcmp for ZERO_KEY may not be considered a security
    critical data, it can lead to more usage of memcmp with pairing keys
    which could introduce more security problems.
    
    Fixes: 455c2ff0a558 ("Bluetooth: Fix BR/EDR out-of-band pairing with only initiator data")
    Fixes: 33155c4aae52 ("Bluetooth: hci_event: Ignore NULL link key")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3b6aa631df0cada8f1c85f920bf9374f64e4e0b3
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Wed Sep 6 21:48:30 2023 +0300

    net/mlx5: Handle fw tracer change ownership event based on MTRC
    
    [ Upstream commit 92fd39634541eb0a11bf1bafbc8ba92d6ddb8dba ]
    
    Currently, whenever fw issues a change ownership event, the PF that owns
    the fw tracer drops its ownership directly and the other PFs try to pick
    up the ownership via what MTRC register suggests.
    
    In some cases, driver releases the ownership of the tracer and reacquires
    it later on. Whenever the driver releases ownership of the tracer, fw
    issues a change ownership event. This event can be delayed and come after
    driver has reacquired ownership of the tracer. Thus the late event will
    trigger the tracer owner PF to release the ownership again and lead to a
    scenario where no PF is owning the tracer.
    
    To prevent the scenario described above, when handling a change
    ownership event, do not drop ownership of the tracer directly, instead
    read the fw MTRC register to retrieve the up-to-date owner of the tracer
    and set it accordingly in driver level.
    
    Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Reviewed-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ead8131372af5d3948eaccfb82a6a2030b9e2aae
Author: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
Date:   Wed Oct 4 19:59:00 2023 -0400

    platform/x86: touchscreen_dmi: Add info for the Positivo C4128B
    
    [ Upstream commit aa7dcba3bae6869122828b144a3cfd231718089d ]
    
    Add information for the Positivo C4128B, a notebook/tablet convertible.
    
    Link: https://github.com/onitake/gsl-firmware/pull/217
    Signed-off-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
    Link: https://lore.kernel.org/r/20231004235900.426240-1-japareaggae@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd127163276921a45edff9b28d91178985893dc6
Author: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Date:   Sun Sep 17 16:18:43 2023 +0000

    HID: multitouch: Add required quirk for Synaptics 0xcd7e device
    
    [ Upstream commit 1437e4547edf41689d7135faaca4222ef0081bc1 ]
    
    Register the Synaptics device as a special multitouch device with certain
    quirks that may improve usability of the touchpad device.
    
    Reported-by: Rain <rain@sunshowers.io>
    Closes: https://lore.kernel.org/linux-input/2bbb8e1d-1793-4df1-810f-cb0137341ff4@app.fastmail.com/
    Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e71ae53f1217e541d2c5a400019abf203ae858b
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Sep 26 15:47:27 2023 -0400

    btrfs: fix some -Wmaybe-uninitialized warnings in ioctl.c
    
    [ Upstream commit 9147b9ded499d9853bdf0e9804b7eaa99c4429ed ]
    
    Jens reported the following warnings from -Wmaybe-uninitialized recent
    Linus' branch.
    
      In file included from ./include/asm-generic/rwonce.h:26,
                       from ./arch/arm64/include/asm/rwonce.h:71,
                       from ./include/linux/compiler.h:246,
                       from ./include/linux/export.h:5,
                       from ./include/linux/linkage.h:7,
                       from ./include/linux/kernel.h:17,
                       from fs/btrfs/ioctl.c:6:
      In function ‘instrument_copy_from_user_before’,
          inlined from ‘_copy_from_user’ at ./include/linux/uaccess.h:148:3,
          inlined from ‘copy_from_user’ at ./include/linux/uaccess.h:183:7,
          inlined from ‘btrfs_ioctl_space_info’ at fs/btrfs/ioctl.c:2999:6,
          inlined from ‘btrfs_ioctl’ at fs/btrfs/ioctl.c:4616:10:
      ./include/linux/kasan-checks.h:38:27: warning: ‘space_args’ may be used
      uninitialized [-Wmaybe-uninitialized]
         38 | #define kasan_check_write __kasan_check_write
      ./include/linux/instrumented.h:129:9: note: in expansion of macro
      ‘kasan_check_write’
        129 |         kasan_check_write(to, n);
            |         ^~~~~~~~~~~~~~~~~
      ./include/linux/kasan-checks.h: In function ‘btrfs_ioctl’:
      ./include/linux/kasan-checks.h:20:6: note: by argument 1 of type ‘const
      volatile void *’ to ‘__kasan_check_write’ declared here
         20 | bool __kasan_check_write(const volatile void *p, unsigned int
            size);
            |      ^~~~~~~~~~~~~~~~~~~
      fs/btrfs/ioctl.c:2981:39: note: ‘space_args’ declared here
       2981 |         struct btrfs_ioctl_space_args space_args;
            |                                       ^~~~~~~~~~
      In function ‘instrument_copy_from_user_before’,
          inlined from ‘_copy_from_user’ at ./include/linux/uaccess.h:148:3,
          inlined from ‘copy_from_user’ at ./include/linux/uaccess.h:183:7,
          inlined from ‘_btrfs_ioctl_send’ at fs/btrfs/ioctl.c:4343:9,
          inlined from ‘btrfs_ioctl’ at fs/btrfs/ioctl.c:4658:10:
      ./include/linux/kasan-checks.h:38:27: warning: ‘args32’ may be used
      uninitialized [-Wmaybe-uninitialized]
         38 | #define kasan_check_write __kasan_check_write
      ./include/linux/instrumented.h:129:9: note: in expansion of macro
      ‘kasan_check_write’
        129 |         kasan_check_write(to, n);
            |         ^~~~~~~~~~~~~~~~~
      ./include/linux/kasan-checks.h: In function ‘btrfs_ioctl’:
      ./include/linux/kasan-checks.h:20:6: note: by argument 1 of type ‘const
      volatile void *’ to ‘__kasan_check_write’ declared here
         20 | bool __kasan_check_write(const volatile void *p, unsigned int
            size);
            |      ^~~~~~~~~~~~~~~~~~~
      fs/btrfs/ioctl.c:4341:49: note: ‘args32’ declared here
       4341 |                 struct btrfs_ioctl_send_args_32 args32;
            |                                                 ^~~~~~
    
    This was due to his config options and having KASAN turned on,
    which adds some extra checks around copy_from_user(), which then
    triggered the -Wmaybe-uninitialized checker for these cases.
    
    Fix the warnings by initializing the different structs we're copying
    into.
    
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 661b4ce3b54abe8683285ef4533909c8a7e3abf4
Author: Kai Uwe Broulik <foss-linux@broulik.de>
Date:   Sun Oct 1 13:47:10 2023 +0200

    drm: panel-orientation-quirks: Add quirk for One Mix 2S
    
    [ Upstream commit cbb7eb2dbd9472816e42a1b0fdb51af49abbf812 ]
    
    The One Mix 2S is a mini laptop with a 1200x1920 portrait screen
    mounted in a landscape oriented clamshell case. Because of the too
    generic DMI strings this entry is also doing bios-date matching.
    
    Signed-off-by: Kai Uwe Broulik <foss-linux@broulik.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231001114710.336172-1-foss-linux@broulik.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b7cae7c35dda1399e16a22a95d49b8f1e5969cb
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri Sep 22 15:55:08 2023 +0800

    ipv4/fib: send notify when delete source address routes
    
    [ Upstream commit 4b2b606075e50cdae62ab2356b0a1e206947c354 ]
    
    After deleting an interface address in fib_del_ifaddr(), the function
    scans the fib_info list for stray entries and calls fib_flush() and
    fib_table_flush(). Then the stray entries will be deleted silently and no
    RTM_DELROUTE notification will be sent.
    
    This lack of notification can make routing daemons, or monitor like
    `ip monitor route` miss the routing changes. e.g.
    
    + ip link add dummy1 type dummy
    + ip link add dummy2 type dummy
    + ip link set dummy1 up
    + ip link set dummy2 up
    + ip addr add 192.168.5.5/24 dev dummy1
    + ip route add 7.7.7.0/24 dev dummy2 src 192.168.5.5
    + ip -4 route
    7.7.7.0/24 dev dummy2 scope link src 192.168.5.5
    192.168.5.0/24 dev dummy1 proto kernel scope link src 192.168.5.5
    + ip monitor route
    + ip addr del 192.168.5.5/24 dev dummy1
    Deleted 192.168.5.0/24 dev dummy1 proto kernel scope link src 192.168.5.5
    Deleted broadcast 192.168.5.255 dev dummy1 table local proto kernel scope link src 192.168.5.5
    Deleted local 192.168.5.5 dev dummy1 table local proto kernel scope host src 192.168.5.5
    
    As Ido reminded, fib_table_flush() isn't only called when an address is
    deleted, but also when an interface is deleted or put down. The lack of
    notification in these cases is deliberate. And commit 7c6bb7d2faaf
    ("net/ipv6: Add knob to skip DELROUTE message on device down") introduced
    a sysctl to make IPv6 behave like IPv4 in this regard. So we can't send
    the route delete notify blindly in fib_table_flush().
    
    To fix this issue, let's add a new flag in "struct fib_info" to track the
    deleted prefer source address routes, and only send notify for them.
    
    After update:
    + ip monitor route
    + ip addr del 192.168.5.5/24 dev dummy1
    Deleted 192.168.5.0/24 dev dummy1 proto kernel scope link src 192.168.5.5
    Deleted broadcast 192.168.5.255 dev dummy1 table local proto kernel scope link src 192.168.5.5
    Deleted local 192.168.5.5 dev dummy1 table local proto kernel scope host src 192.168.5.5
    Deleted 7.7.7.0/24 dev dummy2 scope link src 192.168.5.5
    
    Suggested-by: Thomas Haller <thaller@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20230922075508.848925-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21f85b026dfec532b27012e65ee4ba5645b88708
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Sep 22 09:50:39 2023 -0700

    sky2: Make sure there is at least one frag_addr available
    
    [ Upstream commit 6a70e5cbedaf8ad10528ac9ac114f3ec20f422df ]
    
    In the pathological case of building sky2 with 16k PAGE_SIZE, the
    frag_addr[] array would never be used, so the original code was correct
    that size should be 0. But the compiler now gets upset with 0 size arrays
    in places where it hasn't eliminated the code that might access such an
    array (it can't figure out that in this case an rx skb with fragments
    would never be created). To keep the compiler happy, make sure there is
    at least 1 frag_addr in struct rx_ring_info:
    
       In file included from include/linux/skbuff.h:28,
                        from include/net/net_namespace.h:43,
                        from include/linux/netdevice.h:38,
                        from drivers/net/ethernet/marvell/sky2.c:18:
       drivers/net/ethernet/marvell/sky2.c: In function 'sky2_rx_unmap_skb':
       include/linux/dma-mapping.h:416:36: warning: array subscript i is outside array bounds of 'dma_addr_t[0]' {aka 'long long unsigned int[]'} [-Warray-bounds=]
         416 | #define dma_unmap_page(d, a, s, r) dma_unmap_page_attrs(d, a, s, r, 0)
             |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       drivers/net/ethernet/marvell/sky2.c:1257:17: note: in expansion of macro 'dma_unmap_page'
        1257 |                 dma_unmap_page(&pdev->dev, re->frag_addr[i],
             |                 ^~~~~~~~~~~~~~
       In file included from drivers/net/ethernet/marvell/sky2.c:41:
       drivers/net/ethernet/marvell/sky2.h:2198:25: note: while referencing 'frag_addr'
        2198 |         dma_addr_t      frag_addr[ETH_JUMBO_MTU >> PAGE_SHIFT];
             |                         ^~~~~~~~~
    
    With CONFIG_PAGE_SIZE_16KB=y, PAGE_SHIFT == 14, so:
    
      #define ETH_JUMBO_MTU   9000
    
    causes "ETH_JUMBO_MTU >> PAGE_SHIFT" to be 0. Use "?: 1" to solve this build warning.
    
    Cc: Mirko Lindner <mlindner@marvell.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: netdev@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202309191958.UBw1cjXk-lkp@intel.com/
    Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f06c3a50ef2bb25a194ca711006004f3ae524af4
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Tue Sep 19 00:50:27 2023 +0200

    regulator/core: Revert "fix kobject release warning and memory leak in regulator_register()"
    
    [ Upstream commit 6e800968f6a715c0661716d2ec5e1f56ed9f9c08 ]
    
    This reverts commit 5f4b204b6b8153923d5be8002c5f7082985d153f.
    
    Since rdev->dev now has a release() callback, the proper way of freeing
    the initialized device can be restored.
    
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/d7f469f3f7b1f0e1d52f9a7ede3f3c5703382090.1695077303.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4613414129603fca2a8cb1324eae7101865d03e8
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Mon Sep 25 17:18:56 2023 +0200

    wifi: cfg80211: avoid leaking stack data into trace
    
    [ Upstream commit 334bf33eec5701a1e4e967bcb7cc8611a998334b ]
    
    If the structure is not initialized then boolean types might be copied
    into the tracing data without being initialised. This causes data from
    the stack to leak into the trace and also triggers a UBSAN failure which
    can easily be avoided here.
    
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Link: https://lore.kernel.org/r/20230925171855.a9271ef53b05.I8180bae663984c91a3e036b87f36a640ba409817@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fde6d84daa0f690c252817a25928281ba554bd15
Author: Wen Gong <quic_wgong@quicinc.com>
Date:   Tue Aug 1 02:47:51 2023 -0400

    wifi: mac80211: allow transmitting EAPOL frames with tainted key
    
    [ Upstream commit 61304336c67358d49a989e5e0060d8c99bad6ca8 ]
    
    Lower layer device driver stop/wake TX by calling ieee80211_stop_queue()/
    ieee80211_wake_queue() while hw scan. Sometimes hw scan and PTK rekey are
    running in parallel, when M4 sent from wpa_supplicant arrive while the TX
    queue is stopped, then the M4 will pending send, and then new key install
    from wpa_supplicant. After TX queue wake up by lower layer device driver,
    the M4 will be dropped by below call stack.
    
    When key install started, the current key flag is set KEY_FLAG_TAINTED in
    ieee80211_pairwise_rekey(), and then mac80211 wait key install complete by
    lower layer device driver. Meanwhile ieee80211_tx_h_select_key() will return
    TX_DROP for the M4 in step 12 below, and then ieee80211_free_txskb() called
    by ieee80211_tx_dequeue(), so the M4 will not send and free, then the rekey
    process failed becaue AP not receive M4. Please see details in steps below.
    
    There are a interval between KEY_FLAG_TAINTED set for current key flag and
    install key complete by lower layer device driver, the KEY_FLAG_TAINTED is
    set in this interval, all packet including M4 will be dropped in this
    interval, the interval is step 8~13 as below.
    
    issue steps:
          TX thread                 install key thread
    1.   stop_queue                      -idle-
    2.   sending M4                      -idle-
    3.   M4 pending                      -idle-
    4.     -idle-                  starting install key from wpa_supplicant
    5.     -idle-                  =>ieee80211_key_replace()
    6.     -idle-                  =>ieee80211_pairwise_rekey() and set
                                     currently key->flags |= KEY_FLAG_TAINTED
    7.     -idle-                  =>ieee80211_key_enable_hw_accel()
    8.     -idle-                  =>drv_set_key() and waiting key install
                                     complete from lower layer device driver
    9.   wake_queue                     -waiting state-
    10.  re-sending M4                  -waiting state-
    11.  =>ieee80211_tx_h_select_key()  -waiting state-
    12.  drop M4 by KEY_FLAG_TAINTED    -waiting state-
    13.    -idle-                   install key complete with success/fail
                                      success: clear flag KEY_FLAG_TAINTED
                                      fail: start disconnect
    
    Hence add check in step 11 above to allow the EAPOL send out in the
    interval. If lower layer device driver use the old key/cipher to encrypt
    the M4, then AP received/decrypt M4 correctly, after M4 send out, lower
    layer device driver install the new key/cipher to hardware and return
    success.
    
    If lower layer device driver use new key/cipher to send the M4, then AP
    will/should drop the M4, then it is same result with this issue, AP will/
    should kick out station as well as this issue.
    
    issue log:
    kworker/u16:4-5238  [000]  6456.108926: stop_queue:           phy1 queue:0, reason:0
    wpa_supplicant-961  [003]  6456.119737: rdev_tx_control_port: wiphy_name=phy1 name=wlan0 ifindex=6 dest=ARRAY[9e, 05, 31, 20, 9b, d0] proto=36488 unencrypted=0
    wpa_supplicant-961  [003]  6456.119839: rdev_return_int_cookie: phy1, returned 0, cookie: 504
    wpa_supplicant-961  [003]  6456.120287: rdev_add_key:         phy1, netdev:wlan0(6), key_index: 0, mode: 0, pairwise: true, mac addr: 9e:05:31:20:9b:d0
    wpa_supplicant-961  [003]  6456.120453: drv_set_key:          phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 cipher:0xfac04, flags=0x9, keyidx=0, hw_key_idx=0
    kworker/u16:9-3829  [001]  6456.168240: wake_queue:           phy1 queue:0, reason:0
    kworker/u16:9-3829  [001]  6456.168255: drv_wake_tx_queue:    phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 ac:0 tid:7
    kworker/u16:9-3829  [001]  6456.168305: cfg80211_control_port_tx_status: wdev(1), cookie: 504, ack: false
    wpa_supplicant-961  [003]  6459.167982: drv_return_int:       phy1 - -110
    
    issue call stack:
    nl80211_frame_tx_status+0x230/0x340 [cfg80211]
    cfg80211_control_port_tx_status+0x1c/0x28 [cfg80211]
    ieee80211_report_used_skb+0x374/0x3e8 [mac80211]
    ieee80211_free_txskb+0x24/0x40 [mac80211]
    ieee80211_tx_dequeue+0x644/0x954 [mac80211]
    ath10k_mac_tx_push_txq+0xac/0x238 [ath10k_core]
    ath10k_mac_op_wake_tx_queue+0xac/0xe0 [ath10k_core]
    drv_wake_tx_queue+0x80/0x168 [mac80211]
    __ieee80211_wake_txqs+0xe8/0x1c8 [mac80211]
    _ieee80211_wake_txqs+0xb4/0x120 [mac80211]
    ieee80211_wake_txqs+0x48/0x80 [mac80211]
    tasklet_action_common+0xa8/0x254
    tasklet_action+0x2c/0x38
    __do_softirq+0xdc/0x384
    
    Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
    Link: https://lore.kernel.org/r/20230801064751.25803-1-quic_wgong@quicinc.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8de7f7058314e9d4618d84696f654e6c1e392fcb
Author: Ilan Peer <ilan.peer@intel.com>
Date:   Mon Sep 18 14:10:54 2023 +0300

    wifi: cfg80211: Fix 6GHz scan configuration
    
    [ Upstream commit 0914468adf92296c4cba8a2134e06e3dea150f2e ]
    
    When the scan request includes a non broadcast BSSID, when adding the
    scan parameters for 6GHz collocated scanning, do not include entries
    that do not match the given BSSID.
    
    Signed-off-by: Ilan Peer <ilan.peer@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20230918140607.6d31d2a96baf.I6c4e3e3075d1d1878ee41f45190fdc6b86f18708@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffb060b136dd75a033ced0fc0aed2882c02e8b56
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Sep 15 14:42:27 2023 -0700

    Bluetooth: hci_core: Fix build warnings
    
    [ Upstream commit dcda165706b9fbfd685898d46a6749d7d397e0c0 ]
    
    This fixes the following warnings:
    
    net/bluetooth/hci_core.c: In function ‘hci_register_dev’:
    net/bluetooth/hci_core.c:2620:54: warning: ‘%d’ directive output may
    be truncated writing between 1 and 10 bytes into a region of size 5
    [-Wformat-truncation=]
     2620 |         snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
          |                                                      ^~
    net/bluetooth/hci_core.c:2620:50: note: directive argument in the range
    [0, 2147483647]
     2620 |         snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
          |                                                  ^~~~~~~
    net/bluetooth/hci_core.c:2620:9: note: ‘snprintf’ output between 5 and
    14 bytes into a destination of size 8
     2620 |         snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65f5da6df8975b5df6411a000770ea1722937e7d
Author: Ying Hsu <yinghsu@chromium.org>
Date:   Thu Sep 7 04:39:34 2023 +0000

    Bluetooth: Avoid redundant authentication
    
    [ Upstream commit 1d8e801422d66e4b8c7b187c52196bef94eed887 ]
    
    While executing the Android 13 CTS Verifier Secure Server test on a
    ChromeOS device, it was observed that the Bluetooth host initiates
    authentication for an RFCOMM connection after SSP completes.
    When this happens, some Intel Bluetooth controllers, like AC9560, would
    disconnect with "Connection Rejected due to Security Reasons (0x0e)".
    
    Historically, BlueZ did not mandate this authentication while an
    authenticated combination key was already in use for the connection.
    This behavior was changed since commit 7b5a9241b780
    ("Bluetooth: Introduce requirements for security level 4").
    So, this patch addresses the aforementioned disconnection issue by
    restoring the previous behavior.
    
    Signed-off-by: Ying Hsu <yinghsu@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 115f2c88fde3c71de913f9e7772cfb13149d4010
Author: Ma Ke <make_ruc2021@163.com>
Date:   Mon Sep 18 10:40:59 2023 +0800

    HID: holtek: fix slab-out-of-bounds Write in holtek_kbd_input_event
    
    [ Upstream commit ffe3b7837a2bb421df84d0177481db9f52c93a71 ]
    
    There is a slab-out-of-bounds Write bug in hid-holtek-kbd driver.
    The problem is the driver assumes the device must have an input
    but some malicious devices violate this assumption.
    
    Fix this by checking hid_device's input is non-empty before its usage.
    
    Signed-off-by: Ma Ke <make_ruc2021@163.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a59636cdd84a6f182cea32b0f8569718d81dbbb5
Author: Clément Léger <cleger@rivosinc.com>
Date:   Fri Sep 29 21:16:37 2023 +0200

    tracing: relax trace_event_eval_update() execution with cond_resched()
    
    [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ]
    
    When kernel is compiled without preemption, the eval_map_work_func()
    (which calls trace_event_eval_update()) will not be preempted up to its
    complete execution. This can actually cause a problem since if another
    CPU call stop_machine(), the call will have to wait for the
    eval_map_work_func() function to finish executing in the workqueue
    before being able to be scheduled. This problem was observe on a SMP
    system at boot time, when the CPU calling the initcalls executed
    clocksource_done_booting() which in the end calls stop_machine(). We
    observed a 1 second delay because one CPU was executing
    eval_map_work_func() and was not preempted by the stop_machine() task.
    
    Adding a call to cond_resched() in trace_event_eval_update() allows
    other tasks to be executed and thus continue working asynchronously
    like before without blocking any pending task at boot time.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cleger@rivosinc.com
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Clément Léger <cleger@rivosinc.com>
    Tested-by: Atish Patra <atishp@rivosinc.com>
    Reviewed-by: Atish Patra <atishp@rivosinc.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb60e9c0004253b68254ab952f0c3ad7b495cbb8
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Tue Sep 12 09:08:40 2023 +0900

    ata: libata-eh: Fix compilation warning in ata_eh_link_report()
    
    [ Upstream commit 49728bdc702391902a473b9393f1620eea32acb0 ]
    
    The 6 bytes length of the tries_buf string in ata_eh_link_report() is
    too short and results in a gcc compilation warning with W-!:
    
    drivers/ata/libata-eh.c: In function ‘ata_eh_link_report’:
    drivers/ata/libata-eh.c:2371:59: warning: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 4 [-Wformat-truncation=]
     2371 |                 snprintf(tries_buf, sizeof(tries_buf), " t%d",
          |                                                           ^~
    drivers/ata/libata-eh.c:2371:56: note: directive argument in the range [-2147483648, 4]
     2371 |                 snprintf(tries_buf, sizeof(tries_buf), " t%d",
          |                                                        ^~~~~~
    drivers/ata/libata-eh.c:2371:17: note: ‘snprintf’ output between 4 and 14 bytes into a destination of size 6
     2371 |                 snprintf(tries_buf, sizeof(tries_buf), " t%d",
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     2372 |                          ap->eh_tries);
          |                          ~~~~~~~~~~~~~
    
    Avoid this warning by increasing the string size to 16B.
    
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22c3641bef9c484a1234a03ae5bb8f7710574dba
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Tue Sep 26 10:29:14 2023 +0000

    gpio: timberdale: Fix potential deadlock on &tgpio->lock
    
    [ Upstream commit 9e8bc2dda5a7a8e2babc9975f4b11c9a6196e490 ]
    
    As timbgpio_irq_enable()/timbgpio_irq_disable() callback could be
    executed under irq context, it could introduce double locks on
    &tgpio->lock if it preempts other execution units requiring
    the same locks.
    
    timbgpio_gpio_set()
    --> timbgpio_update_bit()
    --> spin_lock(&tgpio->lock)
    <interrupt>
       --> timbgpio_irq_disable()
       --> spin_lock_irqsave(&tgpio->lock)
    
    This flaw was found by an experimental static analysis tool I am
    developing for irq-related deadlock.
    
    To prevent the potential deadlock, the patch uses spin_lock_irqsave()
    on &tgpio->lock inside timbgpio_gpio_set() to prevent the possible
    deadlock scenario.
    
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4fcf1a0bbd01e8ce71611b9154c2203d38089dd
Author: Jeff Layton <jlayton@kernel.org>
Date:   Wed Sep 13 09:33:12 2023 -0400

    overlayfs: set ctime when setting mtime and atime
    
    [ Upstream commit 03dbab3bba5f009d053635c729d1244f2c8bad38 ]
    
    Nathan reported that he was seeing the new warning in
    setattr_copy_mgtime pop when starting podman containers. Overlayfs is
    trying to set the atime and mtime via notify_change without also
    setting the ctime.
    
    POSIX states that when the atime and mtime are updated via utimes() that
    we must also update the ctime to the current time. The situation with
    overlayfs copy-up is analogies, so add ATTR_CTIME to the bitmask.
    notify_change will fill in the value.
    
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Christian Brauner <brauner@kernel.org>
    Acked-by: Amir Goldstein <amir73il@gmail.com>
    Message-Id: <20230913-ctime-v1-1-c6bc509cbc27@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b472c25a597463cb00a606d28d23d5e0f5f0040
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Sep 23 23:54:06 2023 +0200

    i2c: mux: Avoid potential false error message in i2c_mux_add_adapter
    
    [ Upstream commit b13e59e74ff71a1004e0508107e91e9a84fd7388 ]
    
    I2C_CLASS_DEPRECATED is a flag and not an actual class.
    There's nothing speaking against both, parent and child, having
    I2C_CLASS_DEPRECATED set. Therefore exclude it from the check.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Acked-by: Peter Rosin <peda@axentia.se>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 840b912df51894e4f1cf8df228835098e0e31adc
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue Sep 5 12:15:24 2023 -0400

    btrfs: initialize start_slot in btrfs_log_prealloc_extents
    
    [ Upstream commit b4c639f699349880b7918b861e1bd360442ec450 ]
    
    Jens reported a compiler warning when using
    CONFIG_CC_OPTIMIZE_FOR_SIZE=y that looks like this
    
      fs/btrfs/tree-log.c: In function ‘btrfs_log_prealloc_extents’:
      fs/btrfs/tree-log.c:4828:23: warning: ‘start_slot’ may be used
      uninitialized [-Wmaybe-uninitialized]
       4828 |                 ret = copy_items(trans, inode, dst_path, path,
            |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       4829 |                                  start_slot, ins_nr, 1, 0);
            |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~
      fs/btrfs/tree-log.c:4725:13: note: ‘start_slot’ was declared here
       4725 |         int start_slot;
            |             ^~~~~~~~~~
    
    The compiler is incorrect, as we only use this code when ins_len > 0,
    and when ins_len > 0 we have start_slot properly initialized.  However
    we generally find the -Wmaybe-uninitialized warnings valuable, so
    initialize start_slot to get rid of the warning.
    
    Reported-by: Jens Axboe <axboe@kernel.dk>
    Tested-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9801e2798b637a5dfc9f410287a9dcbc7dcf238a
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Sep 8 18:20:23 2023 +0100

    btrfs: return -EUCLEAN for delayed tree ref with a ref count not equals to 1
    
    [ Upstream commit 1bf76df3fee56d6637718e267f7c34ed70d0c7dc ]
    
    When running a delayed tree reference, if we find a ref count different
    from 1, we return -EIO. This isn't an IO error, as it indicates either a
    bug in the delayed refs code or a memory corruption, so change the error
    code from -EIO to -EUCLEAN. Also tag the branch as 'unlikely' as this is
    not expected to ever happen, and change the error message to print the
    tree block's bytenr without the parenthesis (and there was a missing space
    between the 'block' word and the opening parenthesis), for consistency as
    that's the style we used everywhere else.
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d69131b48feab7dc3ca08268d256e42d0e716fa0
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Sep 11 07:07:38 2023 +0300

    ARM: dts: ti: omap: Fix noisy serial with overrun-throttle-ms for mapphone
    
    [ Upstream commit 5ad37b5e30433afa7a5513e3eb61f69fa0976785 ]
    
    On mapphone devices we may get lots of noise on the micro-USB port in debug
    uart mode until the phy-cpcap-usb driver probes. Let's limit the noise by
    using overrun-throttle-ms.
    
    Note that there is also a related separate issue where the charger cable
    connected may cause random sysrq requests until phy-cpcap-usb probes that
    still remains.
    
    Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Cc: Carl Philipp Klemm <philipp@uvos.xyz>
    Cc: Merlijn Wajer <merlijn@wizzup.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ed14f807f4f768ab06de395c1dfea7a31eea55e
Author: RD Babiera <rdbabiera@google.com>
Date:   Mon Oct 9 21:00:58 2023 +0000

    usb: typec: altmodes/displayport: Signal hpd low when exiting mode
    
    [ Upstream commit 89434b069e460967624903b049e5cf5c9e6b99b9 ]
    
    Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort
    driver currently resets the status and configuration of the port partner.
    The hpd signal is not updated despite being part of the status, so the
    Display stack can still transmit video despite typec_altmode_exit placing
    the lanes in a Safe State.
    
    Set hpd to low when a sent EXIT_MODE message is ACK'ed.
    
    Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
    Cc: stable@vger.kernel.org
    Signed-off-by: RD Babiera <rdbabiera@google.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20231009210057.3773877-2-rdbabiera@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f25a13d318b8eb6fb48673376b585a990e605e93
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 17 23:52:01 2021 +0200

    usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
    
    [ Upstream commit 7f811394878535ed9a6849717de8c2959ae38899 ]
    
    Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
    drivers know about DisplayPort over Type-C hotplug events.
    
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://lore.kernel.org/r/20210817215201.795062-9-hdegoede@redhat.com
    Stable-dep-of: 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when exiting mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ea6a14e8a5512755bbeb0db774385e99448ea8f
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 17 23:51:57 2021 +0200

    drm/connector: Add support for out-of-band hotplug notification (v3)
    
    [ Upstream commit 72ad49682dde3d9de5708b8699dc8e0b44962322 ]
    
    Add a new drm_connector_oob_hotplug_event() function and
    oob_hotplug_event drm_connector_funcs member.
    
    On some hardware a hotplug event notification may come from outside the
    display driver / device. An example of this is some USB Type-C setups
    where the hardware muxes the DisplayPort data and aux-lines but does
    not pass the altmode HPD status bit to the GPU's DP HPD pin.
    
    In cases like this the new drm_connector_oob_hotplug_event() function can
    be used to report these out-of-band events.
    
    Changes in v2:
    - Make drm_connector_oob_hotplug_event() take a fwnode as argument and
      have it call drm_connector_find_by_fwnode() internally. This allows
      making drm_connector_find_by_fwnode() a drm-internal function and
      avoids code outside the drm subsystem potentially holding on the
      a drm_connector reference for a longer period.
    
    Changes in v3:
    - Drop the data argument to the drm_connector_oob_hotplug_event
      function since it is not used atm. This can be re-added later when
      a use for it actually arises.
    
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://lore.kernel.org/r/20210817215201.795062-5-hdegoede@redhat.com
    Stable-dep-of: 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when exiting mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e55f6a8a4986ecd43d235b9b0120e06c400b3d6
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 17 23:51:56 2021 +0200

    drm/connector: Add drm_connector_find_by_fwnode() function (v3)
    
    [ Upstream commit 3d3f7c1e68691574c1d87cd0f9f2348323bc0199 ]
    
    Add a function to find a connector based on a fwnode.
    
    This will be used by the new drm_connector_oob_hotplug_event()
    function which is added by the next patch in this patch-set.
    
    Changes in v2:
    - Complete rewrite to use a global connector list in drm_connector.c
      rather then using a class-dev-iter in drm_sysfs.c
    
    Changes in v3:
    - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h
      (fixes warning reported by kernel test robot <lkp@intel.com>)
    
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://lore.kernel.org/r/20210817215201.795062-4-hdegoede@redhat.com
    Stable-dep-of: 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when exiting mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89b1868bab4883b2abd4796bc1965db1565ad6ad
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 17 23:51:55 2021 +0200

    drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2)
    
    [ Upstream commit 48c429c6d18db115c277b75000152d8fa4cd35d0 ]
    
    Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
    for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
    
    The adding of the fwnode pointer allows drivers to associate a fwnode
    that represents a connector with that connector.
    
    When the new fwnode pointer points to an ACPI-companion, then the new
    acpi_bus_type will cause the ACPI subsys to bind the device instantiated
    for the connector with the fwnode by calling acpi_bind_one(). This will
    result in a firmware_node symlink under /sys/class/card#-<connecter-name>/
    which helps to verify that the fwnode-s and connectors are properly
    matched.
    
    Changes in v2:
    - Make drm_connector_cleanup() call fwnode_handle_put() on
      connector->fwnode and document this
    
    Co-developed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://lore.kernel.org/r/20210817215201.795062-3-hdegoede@redhat.com
    Stable-dep-of: 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when exiting mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86502f1b63aa7d3466d245731673d70ea2c8c9f4
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Aug 17 23:51:54 2021 +0200

    drm/connector: Give connector sysfs devices there own device_type
    
    [ Upstream commit 331de7db3012b8e8e8d77beebc8f743e288d4c42 ]
    
    Give connector sysfs devices there own device_type, this allows us to
    check if a device passed to functions dealing with generic devices is
    a drm_connector or not.
    
    A check like this is necessary in the drm_connector_acpi_bus_match()
    function added in the next patch in this series.
    
    Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://lore.kernel.org/r/20210817215201.795062-2-hdegoede@redhat.com
    Stable-dep-of: 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when exiting mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cedcbf61dfce2717f7133c7e5408524ad36f8268
Author: Daniel Miess <daniel.miess@amd.com>
Date:   Fri Sep 29 13:04:33 2023 -0400

    drm/amd/display: Don't set dpms_off for seamless boot
    
    [ Upstream commit 23645bca98304a2772f0de96f97370dd567d0ae6 ]
    
    [Why]
    eDPs fail to light up with seamless boot enabled
    
    [How]
    When seamless boot is enabled don't configure dpms_off
    in disable_vbios_mode_if_required.
    
    Reviewed-by: Charlene Liu <charlene.liu@amd.com>
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Daniel Miess <daniel.miess@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebba01fcd562b0a9728c5c8c13b199747d4992ed
Author: Yongqiang Sun <yongqiang.sun@amd.com>
Date:   Fri Oct 16 09:25:05 2020 -0400

    drm/amd/display: only check available pipe to disable vbios mode.
    
    [ Upstream commit 850d2fcf3e346a35e4e59e310b867e90e3ef8e5a ]
    
    [Why & How]
    1. only need to check first ODM pipe.
    2. Only need to check eDP which is on.
    
    Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com>
    Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 23645bca9830 ("drm/amd/display: Don't set dpms_off for seamless boot")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ac717000403a24af181c5b6276eb0d694f7b1c5
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Sep 26 09:13:17 2023 +0300

    serial: 8250_omap: Fix errors with no_console_suspend
    
    [ Upstream commit 560706eff7c8e5621b0d63afe0866e0e1906e87e ]
    
    We now get errors on system suspend if no_console_suspend is set as
    reported by Thomas. The errors started with commit 20a41a62618d ("serial:
    8250_omap: Use force_suspend and resume for system suspend").
    
    Let's fix the issue by checking for console_suspend_enabled in the system
    suspend and resume path.
    
    Note that with this fix the checks for console_suspend_enabled in
    omap8250_runtime_suspend() become useless. We now keep runtime PM usage
    count for an attached kernel console starting with commit bedb404e91bb
    ("serial: 8250_port: Don't use power management for kernel console").
    
    Fixes: 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend")
    Cc: stable <stable@kernel.org>
    Cc: Udit Kumar <u-kumar1@ti.com>
    Reported-by: Thomas Richard <thomas.richard@bootlin.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Tested-by: Thomas Richard <thomas.richard@bootlin.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Link: https://lore.kernel.org/r/20230926061319.15140-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be300358b55dd7e2275bb3f7aac8251e10cd01dd
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon May 8 11:20:12 2023 +0300

    serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()
    
    [ Upstream commit 398cecc24846e867b9f90a0bd22730e3df6b05be ]
    
    We must idle the uart only after serial8250_unregister_port(). Otherwise
    unbinding the uart via sysfs while doing cat on the port produces an
    imprecise external abort:
    
    mem_serial_in from omap_8250_pm+0x44/0xf4
    omap_8250_pm from uart_hangup+0xe0/0x194
    uart_hangup from __tty_hangup.part.0+0x37c/0x3a8
    __tty_hangup.part.0 from uart_remove_one_port+0x9c/0x22c
    uart_remove_one_port from serial8250_unregister_port+0x60/0xe8
    serial8250_unregister_port from omap8250_remove+0x6c/0xd0
    omap8250_remove from platform_remove+0x28/0x54
    
    Turns out the driver needs to have runtime PM functional before the
    driver probe calls serial8250_register_8250_port(). And it needs
    runtime PM after driver remove calls serial8250_unregister_port().
    
    On probe, we need to read registers before registering the port in
    omap_serial_fill_features_erratas(). We do that with custom uart_read()
    already.
    
    On remove, after serial8250_unregister_port(), we need to write to the
    uart registers to idle the device. Let's add a custom uart_write() for
    that.
    
    Currently the uart register access depends on port->membase to be
    initialized, which won't work after serial8250_unregister_port().
    Let's use priv->membase instead, and use it for runtime PM related
    functions to remove the dependency to port->membase for early and
    late register access.
    
    Note that during use, we need to check for a valid port in the runtime PM
    related functions. This is needed for the optional wakeup configuration.
    We now need to set the drvdata a bit earlier so it's available for the
    runtime PM functions.
    
    With the port checks in runtime PM functions, the old checks for priv in
    omap8250_runtime_suspend() and omap8250_runtime_resume() functions are no
    longer needed and are removed.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20230508082014.23083-3-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 560706eff7c8 ("serial: 8250_omap: Fix errors with no_console_suspend")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc778e9d7995dece6eadc7ba995e38befd7d4645
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Sep 15 17:31:06 2023 +0300

    xhci: track port suspend state correctly in unsuccessful resume cases
    
    [ Upstream commit d7cdfc319b2bcf6899ab0a05eec0958bc802a9a1 ]
    
    xhci-hub.c tracks suspended ports in a suspended_port bitfield.
    This is checked when responding to a Get_Status(PORT) request to see if a
    port in running U0 state was recently resumed, and adds the required
    USB_PORT_STAT_C_SUSPEND change bit in those cases.
    
    The suspended_port bit was left uncleared if a device is disconnected
    during suspend. The bit remained set even when a new device was connected
    and enumerated. The set bit resulted in a incorrect Get_Status(PORT)
    response with a bogus USB_PORT_STAT_C_SUSPEND change
    bit set once the new device reached U0 link state.
    
    USB_PORT_STAT_C_SUSPEND change bit is only used for USB2 ports, but
    xhci-hub keeps track of both USB2 and USB3 suspended ports.
    
    Cc: stable@vger.kernel.org
    Reported-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Closes: https://lore.kernel.org/linux-usb/d68aa806-b26a-0e43-42fb-b8067325e967@quicinc.com/
    Fixes: 1d5810b6923c ("xhci: Rework port suspend structures for limited ports.")
    Tested-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230915143108.1532163-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c034c6e224d6e7d3cec230e72a89c4ba326f861
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:05 2023 +0200

    xhci: decouple usb2 port resume and get_port_status request handling
    
    [ Upstream commit b0425784b942fffbbdb804896197f1dbccda37c5 ]
    
    The get port status hub request code in xhci-hub.c will complete usb2
    port resume signalling if signalling has been going on for long enough.
    
    The code that completes the resume signalling, and the code that returns
    the port status have gotten too intertwined, so separate them a bit.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-12-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92088dd8862749e100a14fcc4ad49ced60a97e3e
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:04 2023 +0200

    xhci: clear usb2 resume related variables in one place.
    
    [ Upstream commit 0e6275452ce26d7ff274a5c1b15ed581a26f7986 ]
    
    Initially resume related USB2 variables were cleared once port
    successfully resumed to U0. Later code was added to clean up
    stale resume variables in case of port failed to resume to U0.
    
    Clear the variables in one place after port is no longer resuming
    or in suspended U3 state.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-11-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7abc4b18d1a10271ff723cd5a09e0cc03f9a61b
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:03 2023 +0200

    xhci: rename resume_done to resume_timestamp
    
    [ Upstream commit a909d629ae77b97b6288bc3cfe68560454bf79c6 ]
    
    resume_done is just a timestamp, avoid confusing it with completions
    related to port state transitions that are named *_done
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-10-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d44c9285ce354d8735a1fe071285cf5ed0a2241b
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:05:01 2023 +0200

    xhci: move port specific items such as state completions to port structure
    
    [ Upstream commit 2996e9fc00c378987c18ecbafe5624581b18c0d6 ]
    
    Now that we have a port structure for each port it makes sense to
    move per port variables, timestamps and completions there.
    Get rid of storing bitfileds and arrays of port specific items per bus.
    
    Move
    unsigned long           resume_done;
    insigned long           rexit_ports
    struct completion       rexit_done;
    struct completion       u3exit_done;
    
    Rename rexit_ports to rexit_active, and remove a redundant hcd
    speed check while checking if rexit_active is set.
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-8-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2b4de13e5f978eb138c059b2120f64d2e35763a
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Feb 2 17:04:59 2023 +0200

    xhci: cleanup xhci_hub_control port references
    
    [ Upstream commit faaae0190dcd1e230616c85bbc3b339f27ba5b81 ]
    
    Both port number and port structure of a port are referred to several
    times when handing hub requests in xhci.
    
    Use more suitable data types and readable names for these.
    Cleanup only, no functional changes
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230202150505.618915-6-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: d7cdfc319b2b ("xhci: track port suspend state correctly in unsuccessful resume cases")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95b9f1e3927b70a3b5edecf1bcba8c2e363b18b2
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Mar 10 19:42:44 2021 -0800

    usb: core: Track SuperSpeed Plus GenXxY
    
    [ Upstream commit 0299809be415567366b66f248eed93848b8dc9f3 ]
    
    Introduce ssp_rate field to usb_device structure to capture the
    connected SuperSpeed Plus signaling rate generation and lane count with
    the corresponding usb_ssp_rate enum.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/b7805d121e5ae4ad5ae144bd860b6ac04ee47436.1615432770.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: f74a7afc224a ("usb: hub: Guard against accesses to uninitialized BOS descriptors")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6316f592988ebb12a86e0c028a131572c11fcee
Author: Juntong Deng <juntong.deng@outlook.com>
Date:   Wed Sep 27 02:19:44 2023 +0800

    selftests/mm: fix awk usage in charge_reserved_hugetlb.sh and hugetlb_reparenting_test.sh that may cause error
    
    [ Upstream commit bbe246f875d064ecfb872fe4f66152e743dfd22d ]
    
    According to the awk manual, the -e option does not need to be specified
    in front of 'program' (unless you need to mix program-file).
    
    The redundant -e option can cause error when users use awk tools other
    than gawk (for example, mawk does not support the -e option).
    
    Error Example:
    awk: not an option: -e
    
    Link: https://lkml.kernel.org/r/VI1P193MB075228810591AF2FDD7D42C599C3A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM
    Signed-off-by: Juntong Deng <juntong.deng@outlook.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69f40ce372b9269ea90fb747acea53f89b4043e6
Author: Waiman Long <longman@redhat.com>
Date:   Fri Jan 14 14:07:58 2022 -0800

    selftests/vm: make charge_reserved_hugetlb.sh work with existing cgroup setting
    
    [ Upstream commit 209376ed2a8431ccb4c40fdcef11194fc1e749b0 ]
    
    The hugetlb cgroup reservation test charge_reserved_hugetlb.sh assume
    that no cgroup filesystems are mounted before running the test.  That is
    not true in many cases.  As a result, the test fails to run.  Fix that
    by querying the current cgroup mount setting and using the existing
    cgroup setup instead before attempting to freshly mount a cgroup
    filesystem.
    
    Similar change is also made for hugetlb_reparenting_test.sh as well,
    though it still has problem if cgroup v2 isn't used.
    
    The patched test scripts were run on a centos 8 based system to verify
    that they ran properly.
    
    Link: https://lkml.kernel.org/r/20220106201359.1646575-1-longman@redhat.com
    Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Acked-by: Mina Almasry <almasrymina@google.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: bbe246f875d0 ("selftests/mm: fix awk usage in charge_reserved_hugetlb.sh and hugetlb_reparenting_test.sh that may cause error")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb868d8857ae2e46f61c253e2b83263d46503c14
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Sep 12 12:08:27 2023 +0200

    ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA
    
    [ Upstream commit c1ed72171ed580fbf159e703b77685aa4b0d0df5 ]
    
    Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA
    has an ACPI DSDT table that describes IRQ 1 as ActiveLow while
    the kernel overrides it to EdgeHigh.
    
    This prevents the keyboard from working. To fix this issue, add this laptop
    to the skip_override_table so that the kernel does not override IRQ 1.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d0728e7ac04b19126d2d981a76a6b1b92f06857
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date:   Tue Apr 11 20:31:44 2023 +0200

    ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CBA
    
    [ Upstream commit 05cda427126f30ce3fc8ffd82fd6f5196398d502 ]
    
    Like the ASUS ExpertBook B2502CBA and various ASUS Vivobook laptops, the
    ASUS ExpertBook B1502CBA has an ACPI DSDT table that describes IRQ 1 as
    ActiveLow while the kernel overrides it to Edge_High.
    
        $ sudo dmesg | grep DMI
        DMI: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B1502CBA_B1502CBA/B1502CBA, BIOS B1502CBA.300 01/18/2023
        $ grep -A 40 PS2K dsdt.dsl | grep IRQ -A 1
                        IRQ (Level, ActiveLow, Exclusive, )
                            {1}
    
    This prevents the keyboard from working. To fix this issue, add this laptop
    to the skip_override_table so that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217323
    Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3a58c28bff797deda7dcbcd3542c22ec6b94a8f3
Author: Tamim Khan <tamim@fusetak.com>
Date:   Fri Dec 30 00:58:39 2022 -0500

    ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA
    
    [ Upstream commit 77c7248882385397cd7dffe9e1437f59f32ce2de ]
    
    Like the Asus Expertbook B2502CBA and various Asus Vivobook laptops,
    the Asus Expertbook B2402CBA has an ACPI DSDT table that describes IRQ 1
    as ActiveLow while the kernel overrides it to Edge_High. This prevents the
    keyboard from working. To fix this issue, add this laptop to the
    skip_override_table so that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216864
    Tested-by: zelenat <zelenat@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b4659e283bcffb60ce78efb54b40fe9a5fb38c9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Dec 15 10:44:43 2022 +0100

    ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks
    
    [ Upstream commit 7203481fd12b1257938519efb2460ea02b9236ee ]
    
    The Asus ExpertBook B2502 has the same keyboard issue as Asus Vivobook
    K3402ZA/K3502ZA. The kernel overrides IRQ 1 to Edge_High when it
    should be Active_Low.
    
    This patch adds the ExpertBook B2502 model to the existing
    quirk list of Asus laptops with this issue.
    
    Fixes: b5f9223a105d ("ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA")
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2142574
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 980dd4dfb9e8079e544dcb04b008721d40d996cb
Author: Tamim Khan <tamim@fusetak.com>
Date:   Fri Oct 14 01:19:31 2022 -0400

    ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA
    
    [ Upstream commit b5f9223a105d9b56954ad1ca3eace4eaf26c99ed ]
    
    Like the Asus Vivobook K3402ZA/K3502ZA/S5402ZA Asus Vivobook S5602ZA
    has an ACPI DSDT table the describes IRQ 1 as ActiveLow while the kernel
    overrides it to Edge_High. This prevents the keyboard on this laptop
    from working. To fix this add this laptop to the skip_override_table so
    that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216579
    Tested-by: Dzmitry <wrkedm@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0014184cd114e7f1da2922925fdbad7529c2817
Author: Kellen Renshaw <kellen.renshaw@canonical.com>
Date:   Wed Sep 21 10:24:22 2022 -0700

    ACPI: resource: Add ASUS model S5402ZA to quirks
    
    [ Upstream commit 6e5cbe7c4b41824e500acbb42411da692d1435f1 ]
    
    The Asus Vivobook S5402ZA has the same keyboard issue as Asus Vivobook
    K3402ZA/K3502ZA. The kernel overrides IRQ 1 to Edge_High when it
    should be Active_Low.
    
    This patch adds the S5402ZA model to the quirk list.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158
    Tested-by: Kellen Renshaw <kellen.renshaw@canonical.com>
    Signed-off-by: Kellen Renshaw <kellen.renshaw@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f26f0ac38544d9b9566ebe6350d009122ecfeba
Author: Tamim Khan <tamim@fusetak.com>
Date:   Sun Aug 28 23:04:19 2022 -0400

    ACPI: resource: Skip IRQ override on Asus Vivobook K3402ZA/K3502ZA
    
    [ Upstream commit e12dee3736731e24b1e7367f87d66ac0fcd73ce7 ]
    
    In the ACPI DSDT table for Asus VivoBook K3402ZA/K3502ZA
    IRQ 1 is described as ActiveLow; however, the kernel overrides
    it to Edge_High. This prevents the internal keyboard from working
    on these laptops. In order to fix this add these laptops to the
    skip_override_table so that the kernel does not override IRQ 1 to
    Edge_High.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158
    Reviewed-by: Hui Wang <hui.wang@canonical.com>
    Tested-by: Tamim Khan <tamim@fusetak.com>
    Tested-by: Sunand <sunandchakradhar@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffcb69e923aa03ff1aeb27cbf00a95aa5bf3c205
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Sep 15 21:09:05 2021 +0800

    ACPI: resources: Add DMI-based legacy IRQ override quirk
    
    [ Upstream commit 892a012699fc0b91a2ed6309078936191447f480 ]
    
    After the commit 0ec4e55e9f57 ("ACPI: resources: Add checks for ACPI
    IRQ override") is reverted, the keyboard on Medion laptops can't
    work again.
    
    To fix the keyboard issue, add a DMI-based override check that will
    not affect other machines along the lines of prt_quirks[] in
    drivers/acpi/pci_irq.c.
    
    If similar issues are seen on other platforms, the quirk table could
    be expanded in the future.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031
    BugLink: http://bugs.launchpad.net/bugs/1909814
    Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reported-by: Manuel Krause <manuelkrause@netscape.net>
    Tested-by: Manuel Krause <manuelkrause@netscape.net>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a8918b510802e0de137634b442d7ee10a0f0b89
Author: John Garry <john.garry@huawei.com>
Date:   Wed Dec 2 18:36:55 2020 +0800

    ACPI: Drop acpi_dev_irqresource_disabled()
    
    [ Upstream commit 1c3f69b4543af0aad514c127298e5ea40392575d ]
    
    The functionality of acpi_dev_irqresource_disabled() is same as in common
    irqresource_disabled(), so drop acpi_dev_irqresource_disabled() in favour
    of that function.
    
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://lore.kernel.org/r/1606905417-183214-4-git-send-email-john.garry@huawei.com
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 196896455bd10625bed6d81e9e3b114d6d61e2d3
Author: John Garry <john.garry@huawei.com>
Date:   Wed Dec 2 18:36:54 2020 +0800

    resource: Add irqresource_disabled()
    
    [ Upstream commit 9806731db684a475ade1e95d166089b9edbd9da3 ]
    
    Add a common function to set the fields for a irq resource to disabled,
    which mimics what is done in acpi_dev_irqresource_disabled(), with a view
    to replace that function.
    
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://lore.kernel.org/r/1606905417-183214-3-git-send-email-john.garry@huawei.com
    Stable-dep-of: c1ed72171ed5 ("ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit faa9a9d07c06b41919d3f93e907a2b5be2cd3826
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Aug 18 15:27:46 2023 +0300

    thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge
    
    [ Upstream commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d ]
    
    On some systems the IOMMU blocks the first couple of driver ready
    messages to the connection manager firmware as can be seen in below
    excerpts:
    
      thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]
    
    or
    
      DMAR: DRHD: handling fault status reg 2
      DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set
    
    The reason is unknown and hard to debug because we were not able to
    reproduce this locally. This only happens on certain systems with Intel
    Maple Ridge Thunderbolt controller. If there is a device connected when
    the driver is loaded the issue does not happen either. Only when there
    is nothing connected (so typically when the system is booted up).
    
    We can work this around by sending the driver ready several times. After
    a couple of retries the message goes through and the controller works
    just fine. For this reason make the number of retries a parameter for
    icm_request() and then for Maple Ridge (and Titan Ridge as they us the
    same function but this should not matter) increase number of retries
    while shortening the timeout accordingly.
    
    Reported-by: Werner Sembach <wse@tuxedocomputers.com>
    Reported-by: Konrad J Hambrick <kjhambrick@gmail.com>
    Reported-by: Calvin Walton <calvin.walton@kepstin.ca>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 482fa2345f03276b827ff46309f5b0ee711fe672
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Mon Oct 16 14:08:59 2023 +0000

    net: pktgen: Fix interface flags printing
    
    commit 1d30162f35c7a73fc2f8cdcdcdbd690bedb99d1a upstream.
    
    Device flags are displayed incorrectly:
    1) The comparison (i == F_FLOW_SEQ) is always false, because F_FLOW_SEQ
    is equal to (1 << FLOW_SEQ_SHIFT) == 2048, and the maximum value
    of the 'i' variable is (NR_PKT_FLAG - 1) == 17. It should be compared
    with FLOW_SEQ_SHIFT.
    
    2) Similarly to the F_IPSEC flag.
    
    3) Also add spaces to the print end of the string literal "spi:%u"
    to prevent the output from merging with the flag that follows.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: 99c6d3d20d62 ("pktgen: Remove brute-force printing of flags")
    Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 068e4ecea226aaa321d3f82b22d601f899f13ce1
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Oct 17 12:28:27 2023 +0200

    netfilter: nft_set_rbtree: .deactivate fails if element has expired
    
    commit d111692a59c1470ae530cbb39bcf0346c950ecc7 upstream.
    
    This allows to remove an expired element which is not possible in other
    existing set backends, this is more noticeable if gc-interval is high so
    expired elements remain in the tree. On-demand gc also does not help in
    this case, because this is delete element path. Return NULL if element
    has expired.
    
    Fixes: 8d8540c4f5e0 ("netfilter: nft_set_rbtree: add timeout support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cef803e9ed0f9b95e87fbb6bcd90de1100eda24
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Oct 16 14:49:04 2023 +0200

    neighbor: tracing: Move pin6 inside CONFIG_IPV6=y section
    
    commit 2915240eddba96b37de4c7e9a3d0ac6f9548454b upstream.
    
    When CONFIG_IPV6=n, and building with W=1:
    
        In file included from include/trace/define_trace.h:102,
                         from include/trace/events/neigh.h:255,
                         from net/core/net-traces.c:51:
        include/trace/events/neigh.h: In function ‘trace_event_raw_event_neigh_create’:
        include/trace/events/neigh.h:42:34: error: variable ‘pin6’ set but not used [-Werror=unused-but-set-variable]
           42 |                 struct in6_addr *pin6;
              |                                  ^~~~
        include/trace/trace_events.h:402:11: note: in definition of macro ‘DECLARE_EVENT_CLASS’
          402 |         { assign; }                                                     \
              |           ^~~~~~
        include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
           44 |                              PARAMS(assign),                   \
              |                              ^~~~~~
        include/trace/events/neigh.h:23:1: note: in expansion of macro ‘TRACE_EVENT’
           23 | TRACE_EVENT(neigh_create,
              | ^~~~~~~~~~~
        include/trace/events/neigh.h:41:9: note: in expansion of macro ‘TP_fast_assign’
           41 |         TP_fast_assign(
              |         ^~~~~~~~~~~~~~
        In file included from include/trace/define_trace.h:103,
                         from include/trace/events/neigh.h:255,
                         from net/core/net-traces.c:51:
        include/trace/events/neigh.h: In function ‘perf_trace_neigh_create’:
        include/trace/events/neigh.h:42:34: error: variable ‘pin6’ set but not used [-Werror=unused-but-set-variable]
           42 |                 struct in6_addr *pin6;
              |                                  ^~~~
        include/trace/perf.h:51:11: note: in definition of macro ‘DECLARE_EVENT_CLASS’
           51 |         { assign; }                                                     \
              |           ^~~~~~
        include/trace/trace_events.h:44:30: note: in expansion of macro ‘PARAMS’
           44 |                              PARAMS(assign),                   \
              |                              ^~~~~~
        include/trace/events/neigh.h:23:1: note: in expansion of macro ‘TRACE_EVENT’
           23 | TRACE_EVENT(neigh_create,
              | ^~~~~~~~~~~
        include/trace/events/neigh.h:41:9: note: in expansion of macro ‘TP_fast_assign’
           41 |         TP_fast_assign(
              |         ^~~~~~~~~~~~~~
    
    Indeed, the variable pin6 is declared and initialized unconditionally,
    while it is only used and needlessly re-initialized when support for
    IPv6 is enabled.
    
    Fix this by dropping the unused variable initialization, and moving the
    variable declaration inside the existing section protected by a check
    for CONFIG_IPV6.
    
    Fixes: fc651001d2c5ca4f ("neighbor: Add tracepoint to __neigh_create")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Simon Horman <horms@kernel.org> # build-tested
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36848adbdebaedf38ea4e9d9989200be6446ec82
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Tue Oct 17 11:36:02 2023 -0300

    net/sched: sch_hfsc: upgrade 'rt' to 'sc' when it becomes a inner curve
    
    commit a13b67c9a015c4e21601ef9aa4ec9c5d972df1b4 upstream.
    
    Christian Theune says:
       I upgraded from 6.1.38 to 6.1.55 this morning and it broke my traffic shaping script,
       leaving me with a non-functional uplink on a remote router.
    
    A 'rt' curve cannot be used as a inner curve (parent class), but we were
    allowing such configurations since the qdisc was introduced. Such
    configurations would trigger a UAF as Budimir explains:
       The parent will have vttree_insert() called on it in init_vf(),
       but will not have vttree_remove() called on it in update_vf()
       because it does not have the HFSC_FSC flag set.
    
    The qdisc always assumes that inner classes have the HFSC_FSC flag set.
    This is by design as it doesn't make sense 'qdisc wise' for an 'rt'
    curve to be an inner curve.
    
    Budimir's original patch disallows users to add classes with a 'rt'
    parent, but this is too strict as it breaks users that have been using
    'rt' as a inner class. Another approach, taken by this patch, is to
    upgrade the inner 'rt' into a 'sc', warning the user in the process.
    It avoids the UAF reported by Budimir while also being more permissive
    to bad scripts/users/code using 'rt' as a inner class.
    
    Users checking the `tc class ls [...]` or `tc class get [...]` dumps would
    observe the curve change and are potentially breaking with this change.
    
    v1->v2: https://lore.kernel.org/all/20231013151057.2611860-1-pctammela@mojatatu.com/
    - Correct 'Fixes' tag and merge with revert (Jakub)
    
    Cc: Christian Theune <ct@flyingcircus.io>
    Cc: Budimir Markovic <markovicbudimir@gmail.com>
    Fixes: b3d26c5702c7 ("net/sched: sch_hfsc: Ensure inner classes have fsc curve")
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20231017143602.3191556-1-pctammela@mojatatu.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 923e47c0b40a92d34c4b91299b6637f6747a2440
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Oct 11 11:24:19 2023 +0800

    net: dsa: bcm_sf2: Fix possible memory leak in bcm_sf2_mdio_register()
    
    commit 61b40cefe51af005c72dbdcf975a3d166c6e6406 upstream.
    
    In bcm_sf2_mdio_register(), the class_find_device() will call get_device()
    to increment reference count for priv->master_mii_bus->dev if
    of_mdio_find_bus() succeeds. If mdiobus_alloc() or mdiobus_register()
    fails, it will call get_device() twice without decrement reference count
    for the device. And it is the same if bcm_sf2_mdio_register() succeeds but
    fails in bcm_sf2_sw_probe(), or if bcm_sf2_sw_probe() succeeds. If the
    reference count has not decremented to zero, the dev related resource will
    not be freed.
    
    So remove the get_device() in bcm_sf2_mdio_register(), and call
    put_device() if mdiobus_alloc() or mdiobus_register() fails and in
    bcm_sf2_mdio_unregister() to solve the issue.
    
    And as Simon suggested, unwind from errors for bcm_sf2_mdio_register() and
    just return 0 if it succeeds to make it cleaner.
    
    Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Suggested-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20231011032419.2423290-1-ruanjinjie@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a53fc0641683755b3334d35fbd465ec838206747
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Wed Oct 11 16:33:32 2023 -0700

    i40e: prevent crash on probe if hw registers have invalid values
    
    commit fc6f716a5069180c40a8c9b63631e97da34f64a3 upstream.
    
    The hardware provides the indexes of the first and the last available
    queue and VF. From the indexes, the driver calculates the numbers of
    queues and VFs. In theory, a faulty device might say the last index is
    smaller than the first index. In that case, the driver's calculation
    would underflow, it would attempt to write to non-existent registers
    outside of the ioremapped range and crash.
    
    I ran into this not by having a faulty device, but by an operator error.
    I accidentally ran a QE test meant for i40e devices on an ice device.
    The test used 'echo i40e > /sys/...ice PCI device.../driver_override',
    bound the driver to the device and crashed in one of the wr32 calls in
    i40e_clear_hw.
    
    Add checks to prevent underflows in the calculations of num_queues and
    num_vfs. With this fix, the wrong device probing reports errors and
    returns a failure without crashing.
    
    Fixes: 838d41d92a90 ("i40e: clear all queues and interrupts")
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Link: https://lore.kernel.org/r/20231011233334.336092-2-jacob.e.keller@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b5661bda3920223a523e3c2c0b1ae57fc8bc5c1
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Oct 16 20:28:10 2023 +0300

    net: usb: smsc95xx: Fix an error code in smsc95xx_reset()
    
    commit c53647a5df9e66dd9fedf240198e1fe50d88c286 upstream.
    
    Return a negative error code instead of success.
    
    Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/147927f0-9ada-45cc-81ff-75a19dd30b76@moroto.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 250cd610f8c46788914b8bfe641c8ec6f8db036c
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 17 19:23:04 2023 +0000

    ipv4: fib: annotate races around nh->nh_saddr_genid and nh->nh_saddr
    
    commit 195374d893681da43a39796e53b30ac4f20400c4 upstream.
    
    syzbot reported a data-race while accessing nh->nh_saddr_genid [1]
    
    Add annotations, but leave the code lazy as intended.
    
    [1]
    BUG: KCSAN: data-race in fib_select_path / fib_select_path
    
    write to 0xffff8881387166f0 of 4 bytes by task 6778 on cpu 1:
    fib_info_update_nhc_saddr net/ipv4/fib_semantics.c:1334 [inline]
    fib_result_prefsrc net/ipv4/fib_semantics.c:1354 [inline]
    fib_select_path+0x292/0x330 net/ipv4/fib_semantics.c:2269
    ip_route_output_key_hash_rcu+0x659/0x12c0 net/ipv4/route.c:2810
    ip_route_output_key_hash net/ipv4/route.c:2644 [inline]
    __ip_route_output_key include/net/route.h:134 [inline]
    ip_route_output_flow+0xa6/0x150 net/ipv4/route.c:2872
    send4+0x1f5/0x520 drivers/net/wireguard/socket.c:61
    wg_socket_send_skb_to_peer+0x94/0x130 drivers/net/wireguard/socket.c:175
    wg_socket_send_buffer_to_peer+0xd6/0x100 drivers/net/wireguard/socket.c:200
    wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline]
    wg_packet_handshake_send_worker+0x10c/0x150 drivers/net/wireguard/send.c:51
    process_one_work kernel/workqueue.c:2630 [inline]
    process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
    worker_thread+0x525/0x730 kernel/workqueue.c:2784
    kthread+0x1d7/0x210 kernel/kthread.c:388
    ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
    ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
    
    read to 0xffff8881387166f0 of 4 bytes by task 6759 on cpu 0:
    fib_result_prefsrc net/ipv4/fib_semantics.c:1350 [inline]
    fib_select_path+0x1cb/0x330 net/ipv4/fib_semantics.c:2269
    ip_route_output_key_hash_rcu+0x659/0x12c0 net/ipv4/route.c:2810
    ip_route_output_key_hash net/ipv4/route.c:2644 [inline]
    __ip_route_output_key include/net/route.h:134 [inline]
    ip_route_output_flow+0xa6/0x150 net/ipv4/route.c:2872
    send4+0x1f5/0x520 drivers/net/wireguard/socket.c:61
    wg_socket_send_skb_to_peer+0x94/0x130 drivers/net/wireguard/socket.c:175
    wg_socket_send_buffer_to_peer+0xd6/0x100 drivers/net/wireguard/socket.c:200
    wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline]
    wg_packet_handshake_send_worker+0x10c/0x150 drivers/net/wireguard/send.c:51
    process_one_work kernel/workqueue.c:2630 [inline]
    process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
    worker_thread+0x525/0x730 kernel/workqueue.c:2784
    kthread+0x1d7/0x210 kernel/kthread.c:388
    ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
    ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
    
    value changed: 0x959d3217 -> 0x959d3218
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 6759 Comm: kworker/u4:15 Not tainted 6.6.0-rc4-syzkaller-00029-gcbf3a2cb156a #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
    Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
    
    Fixes: 436c3b66ec98 ("ipv4: Invalidate nexthop cache nh_saddr more correctly.")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20231017192304.82626-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cef1a2d5c22f598da5b0431baf1a90609ce23a2
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 16 18:08:51 2023 +0000

    tun: prevent negative ifindex
    
    commit cbfbfe3aee718dc4c3c837f5d2463170ee59d78c upstream.
    
    After commit 956db0a13b47 ("net: warn about attempts to register
    negative ifindex") syzbot is able to trigger the following splat.
    
    Negative ifindex are not supported.
    
    WARNING: CPU: 1 PID: 6003 at net/core/dev.c:9596 dev_index_reserve+0x104/0x210
    Modules linked in:
    CPU: 1 PID: 6003 Comm: syz-executor926 Not tainted 6.6.0-rc4-syzkaller-g19af4a4ed414 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
    pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : dev_index_reserve+0x104/0x210
    lr : dev_index_reserve+0x100/0x210
    sp : ffff800096a878e0
    x29: ffff800096a87930 x28: ffff0000d04380d0 x27: ffff0000d04380f8
    x26: ffff0000d04380f0 x25: 1ffff00012d50f20 x24: 1ffff00012d50f1c
    x23: dfff800000000000 x22: ffff8000929c21c0 x21: 00000000ffffffea
    x20: ffff0000d04380e0 x19: ffff800096a87900 x18: ffff800096a874c0
    x17: ffff800084df5008 x16: ffff80008051f9c4 x15: 0000000000000001
    x14: 1fffe0001a087198 x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
    x8 : ffff0000d41c9bc0 x7 : 0000000000000000 x6 : 0000000000000000
    x5 : ffff800091763d88 x4 : 0000000000000000 x3 : ffff800084e04748
    x2 : 0000000000000001 x1 : 00000000fead71c7 x0 : 0000000000000000
    Call trace:
    dev_index_reserve+0x104/0x210
    register_netdevice+0x598/0x1074 net/core/dev.c:10084
    tun_set_iff+0x630/0xb0c drivers/net/tun.c:2850
    __tun_chr_ioctl+0x788/0x2af8 drivers/net/tun.c:3118
    tun_chr_ioctl+0x38/0x4c drivers/net/tun.c:3403
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:871 [inline]
    __se_sys_ioctl fs/ioctl.c:857 [inline]
    __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:857
    __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
    invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
    el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
    do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
    el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
    el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
    el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
    irq event stamp: 11348
    hardirqs last enabled at (11347): [<ffff80008a716574>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]
    hardirqs last enabled at (11347): [<ffff80008a716574>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194
    hardirqs last disabled at (11348): [<ffff80008a627820>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:436
    softirqs last enabled at (11138): [<ffff8000887ca53c>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
    softirqs last enabled at (11138): [<ffff8000887ca53c>] release_sock+0x15c/0x1b0 net/core/sock.c:3531
    softirqs last disabled at (11136): [<ffff8000887ca41c>] spin_lock_bh include/linux/spinlock.h:356 [inline]
    softirqs last disabled at (11136): [<ffff8000887ca41c>] release_sock+0x3c/0x1b0 net/core/sock.c:3518
    
    Fixes: fb7589a16216 ("tun: Add ability to create tun device with given index")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Link: https://lore.kernel.org/r/20231016180851.3560092-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f828e15db3c736a2150d546069b894eacca8e4bd
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 17 12:45:26 2023 +0000

    tcp: tsq: relax tcp_small_queue_check() when rtx queue contains a single skb
    
    commit f921a4a5bffa8a0005b190fb9421a7fc1fd716b6 upstream.
    
    In commit 75eefc6c59fd ("tcp: tsq: add a shortcut in tcp_small_queue_check()")
    we allowed to send an skb regardless of TSQ limits being hit if rtx queue
    was empty or had a single skb, in order to better fill the pipe
    when/if TX completions were slow.
    
    Then later, commit 75c119afe14f ("tcp: implement rb-tree based
    retransmit queue") accidentally removed the special case for
    one skb in rtx queue.
    
    Stefan Wahren reported a regression in single TCP flow throughput
    using a 100Mbit fec link, starting from commit 65466904b015 ("tcp: adjust
    TSO packet sizes based on min_rtt"). This last commit only made the
    regression more visible, because it locked the TCP flow on a particular
    behavior where TSQ prevented two skbs being pushed downstream,
    adding silences on the wire between each TSO packet.
    
    Many thanks to Stefan for his invaluable help !
    
    Fixes: 75c119afe14f ("tcp: implement rb-tree based retransmit queue")
    Link: https://lore.kernel.org/netdev/7f31ddc8-9971-495e-a1f6-819df542e0af@gmx.net/
    Reported-by: Stefan Wahren <wahrenst@gmx.net>
    Tested-by: Stefan Wahren <wahrenst@gmx.net>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Link: https://lore.kernel.org/r/20231017124526.4060202-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c39c31c5265b743dd02a82d2d6cb2f0222f57864
Author: Neal Cardwell <ncardwell@google.com>
Date:   Sun Oct 15 13:47:00 2023 -0400

    tcp: fix excessive TLP and RACK timeouts from HZ rounding
    
    commit 1c2709cfff1dedbb9591e989e2f001484208d914 upstream.
    
    We discovered from packet traces of slow loss recovery on kernels with
    the default HZ=250 setting (and min_rtt < 1ms) that after reordering,
    when receiving a SACKed sequence range, the RACK reordering timer was
    firing after about 16ms rather than the desired value of roughly
    min_rtt/4 + 2ms. The problem is largely due to the RACK reorder timer
    calculation adding in TCP_TIMEOUT_MIN, which is 2 jiffies. On kernels
    with HZ=250, this is 2*4ms = 8ms. The TLP timer calculation has the
    exact same issue.
    
    This commit fixes the TLP transmit timer and RACK reordering timer
    floor calculation to more closely match the intended 2ms floor even on
    kernels with HZ=250. It does this by adding in a new
    TCP_TIMEOUT_MIN_US floor of 2000 us and then converting to jiffies,
    instead of the current approach of converting to jiffies and then
    adding th TCP_TIMEOUT_MIN value of 2 jiffies.
    
    Our testing has verified that on kernels with HZ=1000, as expected,
    this does not produce significant changes in behavior, but on kernels
    with the default HZ=250 the latency improvement can be large. For
    example, our tests show that for HZ=250 kernels at low RTTs this fix
    roughly halves the latency for the RACK reorder timer: instead of
    mostly firing at 16ms it mostly fires at 8ms.
    
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Fixes: bb4d991a28cc ("tcp: adjust tail loss probe timeout")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20231015174700.2206872-1-ncardwell.sw@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 805b38062e2857cc34f3cf2b1bd44980c6ba8944
Author: Josua Mayer <josua@solid-run.com>
Date:   Wed Oct 4 18:39:28 2023 +0200

    net: rfkill: gpio: prevent value glitch during probe
    
    commit b2f750c3a80b285cd60c9346f8c96bd0a2a66cde upstream.
    
    When either reset- or shutdown-gpio have are initially deasserted,
    e.g. after a reboot - or when the hardware does not include pull-down,
    there will be a short toggle of both IOs to logical 0 and back to 1.
    
    It seems that the rfkill default is unblocked, so the driver should not
    glitch to output low during probe.
    It can lead e.g. to unexpected lte modem reconnect:
    
    [1] root@localhost:~# dmesg | grep "usb 2-1"
    [    2.136124] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
    [   21.215278] usb 2-1: USB disconnect, device number 2
    [   28.833977] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
    
    The glitch has been discovered on an arm64 board, now that device-tree
    support for the rfkill-gpio driver has finally appeared :).
    
    Change the flags for devm_gpiod_get_optional from GPIOD_OUT_LOW to
    GPIOD_ASIS to avoid any glitches.
    The rfkill driver will set the intended value during rfkill_sync_work.
    
    Fixes: 7176ba23f8b5 ("net: rfkill: add generic gpio rfkill driver")
    Signed-off-by: Josua Mayer <josua@solid-run.com>
    Link: https://lore.kernel.org/r/20231004163928.14609-1-josua@solid-run.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8023c7e90007861a353b9e1a3abd9e158369c104
Author: Ma Ke <make_ruc2021@163.com>
Date:   Sat Oct 7 08:59:53 2023 +0800

    net: ipv6: fix return value check in esp_remove_trailer
    
    commit dad4e491e30b20f4dc615c9da65d2142d703b5c2 upstream.
    
    In esp_remove_trailer(), to avoid an unexpected result returned by
    pskb_trim, we should check the return value of pskb_trim().
    
    Signed-off-by: Ma Ke <make_ruc2021@163.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ca00d93f2b1cde551f91cad17d7c53af8e3bd29
Author: Ma Ke <make_ruc2021@163.com>
Date:   Mon Oct 9 09:13:37 2023 +0800

    net: ipv4: fix return value check in esp_remove_trailer
    
    commit 513f61e2193350c7a345da98559b80f61aec4fa6 upstream.
    
    In esp_remove_trailer(), to avoid an unexpected result returned by
    pskb_trim, we should check the return value of pskb_trim().
    
    Signed-off-by: Ma Ke <make_ruc2021@163.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ba4eec4f40d4ea82d77258179f76eeb6fce0f7f
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 5 13:23:03 2023 +0000

    xfrm: interface: use DEV_STATS_INC()
    
    commit f7c4e3e5d4f6609b4725a97451948ca2e425379a upstream.
    
    syzbot/KCSAN reported data-races in xfrm whenever dev->stats fields
    are updated.
    
    It appears all of these updates can happen from multiple cpus.
    
    Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
    
    BUG: KCSAN: data-race in xfrmi_xmit / xfrmi_xmit
    
    read-write to 0xffff88813726b160 of 8 bytes by task 23986 on cpu 1:
    xfrmi_xmit+0x74e/0xb20 net/xfrm/xfrm_interface_core.c:583
    __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
    netdev_start_xmit include/linux/netdevice.h:4903 [inline]
    xmit_one net/core/dev.c:3544 [inline]
    dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560
    __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340
    dev_queue_xmit include/linux/netdevice.h:3082 [inline]
    neigh_connected_output+0x231/0x2a0 net/core/neighbour.c:1581
    neigh_output include/net/neighbour.h:542 [inline]
    ip_finish_output2+0x74a/0x850 net/ipv4/ip_output.c:230
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:318
    NF_HOOK_COND include/linux/netfilter.h:293 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:432
    dst_output include/net/dst.h:458 [inline]
    ip_local_out net/ipv4/ip_output.c:127 [inline]
    ip_send_skb+0x72/0xe0 net/ipv4/ip_output.c:1487
    udp_send_skb+0x6a4/0x990 net/ipv4/udp.c:963
    udp_sendmsg+0x1249/0x12d0 net/ipv4/udp.c:1246
    inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:840
    sock_sendmsg_nosec net/socket.c:730 [inline]
    sock_sendmsg net/socket.c:753 [inline]
    ____sys_sendmsg+0x37c/0x4d0 net/socket.c:2540
    ___sys_sendmsg net/socket.c:2594 [inline]
    __sys_sendmmsg+0x269/0x500 net/socket.c:2680
    __do_sys_sendmmsg net/socket.c:2709 [inline]
    __se_sys_sendmmsg net/socket.c:2706 [inline]
    __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2706
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read-write to 0xffff88813726b160 of 8 bytes by task 23987 on cpu 0:
    xfrmi_xmit+0x74e/0xb20 net/xfrm/xfrm_interface_core.c:583
    __netdev_start_xmit include/linux/netdevice.h:4889 [inline]
    netdev_start_xmit include/linux/netdevice.h:4903 [inline]
    xmit_one net/core/dev.c:3544 [inline]
    dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560
    __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340
    dev_queue_xmit include/linux/netdevice.h:3082 [inline]
    neigh_connected_output+0x231/0x2a0 net/core/neighbour.c:1581
    neigh_output include/net/neighbour.h:542 [inline]
    ip_finish_output2+0x74a/0x850 net/ipv4/ip_output.c:230
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:318
    NF_HOOK_COND include/linux/netfilter.h:293 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:432
    dst_output include/net/dst.h:458 [inline]
    ip_local_out net/ipv4/ip_output.c:127 [inline]
    ip_send_skb+0x72/0xe0 net/ipv4/ip_output.c:1487
    udp_send_skb+0x6a4/0x990 net/ipv4/udp.c:963
    udp_sendmsg+0x1249/0x12d0 net/ipv4/udp.c:1246
    inet_sendmsg+0x63/0x80 net/ipv4/af_inet.c:840
    sock_sendmsg_nosec net/socket.c:730 [inline]
    sock_sendmsg net/socket.c:753 [inline]
    ____sys_sendmsg+0x37c/0x4d0 net/socket.c:2540
    ___sys_sendmsg net/socket.c:2594 [inline]
    __sys_sendmmsg+0x269/0x500 net/socket.c:2680
    __do_sys_sendmmsg net/socket.c:2709 [inline]
    __se_sys_sendmmsg net/socket.c:2706 [inline]
    __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2706
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00000000000010d7 -> 0x00000000000010d8
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 23987 Comm: syz-executor.5 Not tainted 6.5.0-syzkaller-10885-g0468be89b3fa #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
    
    Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d78b9dc79d5a3c44d8106e6b71f2b14ea86804e
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 8 18:13:59 2023 +0000

    xfrm: fix a data-race in xfrm_gen_index()
    
    commit 3e4bc23926b83c3c67e5f61ae8571602754131a6 upstream.
    
    xfrm_gen_index() mutual exclusion uses net->xfrm.xfrm_policy_lock.
    
    This means we must use a per-netns idx_generator variable,
    instead of a static one.
    Alternative would be to use an atomic variable.
    
    syzbot reported:
    
    BUG: KCSAN: data-race in xfrm_sk_policy_insert / xfrm_sk_policy_insert
    
    write to 0xffffffff87005938 of 4 bytes by task 29466 on cpu 0:
    xfrm_gen_index net/xfrm/xfrm_policy.c:1385 [inline]
    xfrm_sk_policy_insert+0x262/0x640 net/xfrm/xfrm_policy.c:2347
    xfrm_user_policy+0x413/0x540 net/xfrm/xfrm_state.c:2639
    do_ipv6_setsockopt+0x1317/0x2ce0 net/ipv6/ipv6_sockglue.c:943
    ipv6_setsockopt+0x57/0x130 net/ipv6/ipv6_sockglue.c:1012
    rawv6_setsockopt+0x21e/0x410 net/ipv6/raw.c:1054
    sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
    __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
    __do_sys_setsockopt net/socket.c:2274 [inline]
    __se_sys_setsockopt net/socket.c:2271 [inline]
    __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffffffff87005938 of 4 bytes by task 29460 on cpu 1:
    xfrm_sk_policy_insert+0x13e/0x640
    xfrm_user_policy+0x413/0x540 net/xfrm/xfrm_state.c:2639
    do_ipv6_setsockopt+0x1317/0x2ce0 net/ipv6/ipv6_sockglue.c:943
    ipv6_setsockopt+0x57/0x130 net/ipv6/ipv6_sockglue.c:1012
    rawv6_setsockopt+0x21e/0x410 net/ipv6/raw.c:1054
    sock_common_setsockopt+0x61/0x70 net/core/sock.c:3697
    __sys_setsockopt+0x1c9/0x230 net/socket.c:2263
    __do_sys_setsockopt net/socket.c:2274 [inline]
    __se_sys_setsockopt net/socket.c:2271 [inline]
    __x64_sys_setsockopt+0x66/0x80 net/socket.c:2271
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00006ad8 -> 0x00006b18
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 29460 Comm: syz-executor.1 Not tainted 6.5.0-rc5-syzkaller-00243-g9106536c1aa3 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
    
    Fixes: 1121994c803f ("netns xfrm: policy insertion in netns")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6c3d0b9f2e4cbb53dd0c2a78baef8bae5b1a46
Author: Manish Chopra <manishc@marvell.com>
Date:   Fri Oct 13 18:48:12 2023 +0530

    qed: fix LL2 RX buffer allocation
    
    commit 2f3389c73832ad90b63208c0fc281ad080114c7a upstream.
    
    Driver allocates the LL2 rx buffers from kmalloc()
    area to construct the skb using slab_build_skb()
    
    The required size allocation seems to have overlooked
    for accounting both skb_shared_info size and device
    placement padding bytes which results into the below
    panic when doing skb_put() for a standard MTU sized frame.
    
    skbuff: skb_over_panic: text:ffffffffc0b0225f len:1514 put:1514
    head:ff3dabceaf39c000 data:ff3dabceaf39c042 tail:0x62c end:0x566
    dev:<NULL>
    …
    skb_panic+0x48/0x4a
    skb_put.cold+0x10/0x10
    qed_ll2b_complete_rx_packet+0x14f/0x260 [qed]
    qed_ll2_rxq_handle_completion.constprop.0+0x169/0x200 [qed]
    qed_ll2_rxq_completion+0xba/0x320 [qed]
    qed_int_sp_dpc+0x1a7/0x1e0 [qed]
    
    This patch fixes this by accouting skb_shared_info and device
    placement padding size bytes when allocating the buffers.
    
    Cc: David S. Miller <davem@davemloft.net>
    Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support")
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88c493297e4011958cf5a73098272fa1a64998e6
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Oct 12 16:28:01 2023 +0300

    drm/i915: Retry gtt fault when out of fence registers
    
    commit e339c6d628fe66c9b64bf31040a55770952aec57 upstream.
    
    If we can't find a free fence register to handle a fault in the GMADR
    range just return VM_FAULT_NOPAGE without populating the PTE so that
    userspace will retry the access and trigger another fault. Eventually
    we should find a free fence and the fault will get properly handled.
    
    A further improvement idea might be to reserve a fence (or one per CPU?)
    for the express purpose of handling faults without having to retry. But
    that would require some additional work.
    
    Looks like this may have gotten broken originally by
    commit 39965b376601 ("drm/i915: don't trash the gtt when running out of fences")
    as that changed the errno to -EDEADLK which wasn't handle by the gtt
    fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix
    -EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK
    was now getting used for the ww mutex dance. So this fix only makes
    sense after that last commit.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479
    Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231012132801.16292-1-ville.syrjala@linux.intel.com
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    (cherry picked from commit 7f403caabe811b88ab0de3811ff3f4782c415761)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e985d78bdcf37f7ef73666a43b0d2407715f00d3
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Mon Oct 2 13:54:28 2023 +0300

    nvmet-tcp: Fix a possible UAF in queue intialization setup
    
    commit d920abd1e7c4884f9ecd0749d1921b7ab19ddfbd upstream.
    
    From Alon:
    "Due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel,
    a malicious user can cause a UAF and a double free, which may lead to
    RCE (may also lead to an LPE in case the attacker already has local
    privileges)."
    
    Hence, when a queue initialization fails after the ahash requests are
    allocated, it is guaranteed that the queue removal async work will be
    called, hence leave the deallocation to the queue removal.
    
    Also, be extra careful not to continue processing the socket, so set
    queue rcv_state to NVMET_TCP_RECV_ERR upon a socket error.
    
    Cc: stable@vger.kernel.org
    Reported-by: Alon Zahavi <zahavi.alon@gmail.com>
    Tested-by: Alon Zahavi <zahavi.alon@gmail.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 287401f92c57dd0006ab9c18295edc42ef08f87d
Author: Florian Westphal <fw@strlen.de>
Date:   Sun Oct 8 19:36:53 2023 +0200

    netfilter: nft_payload: fix wrong mac header matching
    
    commit d351c1ea2de3e36e608fc355d8ae7d0cc80e6cd6 upstream.
    
    mcast packets get looped back to the local machine.
    Such packets have a 0-length mac header, we should treat
    this like "mac header not set" and abort rule evaluation.
    
    As-is, we just copy data from the network header instead.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Reported-by: Blažej Krajňák <krajnak@levonet.sk>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe37e56ed47d8789f2be2076fed7c1a6085c60de
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Oct 18 11:23:53 2023 -0700

    tcp: check mptcp-level constraints for backlog coalescing
    
    commit 6db8a37dfc541e059851652cfd4f0bb13b8ff6af upstream.
    
    The MPTCP protocol can acquire the subflow-level socket lock and
    cause the tcp backlog usage. When inserting new skbs into the
    backlog, the stack will try to coalesce them.
    
    Currently, we have no check in place to ensure that such coalescing
    will respect the MPTCP-level DSS, and that may cause data stream
    corruption, as reported by Christoph.
    
    Address the issue by adding the relevant admission check for coalescing
    in tcp_add_backlog().
    
    Note the issue is not easy to reproduce, as the MPTCP protocol tries
    hard to avoid acquiring the subflow-level socket lock.
    
    Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/420
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-2-17ecb002e41d@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6550cbe25de182f6c0176909a90b324cb375133f
Author: Joerg Roedel <jroedel@suse.de>
Date:   Mon Oct 16 14:42:50 2023 +0200

    x86/sev: Check for user-space IOIO pointing to kernel space
    
    Upstream commit: 63e44bc52047f182601e7817da969a105aa1f721
    
    Check the memory operand of INS/OUTS before emulating the instruction.
    The #VC exception can get raised from user-space, but the memory operand
    can be manipulated to access kernel memory before the emulation actually
    begins and after the exception handler has run.
    
      [ bp: Massage commit message. ]
    
    Fixes: 597cfe48212a ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler")
    Reported-by: Tom Dohrmann <erbse.13@gmx.de>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb9ba7dafbe18e027e335f74372ca65f07f7edd
Author: Joerg Roedel <jroedel@suse.de>
Date:   Wed Jun 21 17:42:42 2023 +0200

    x86/sev: Check IOBM for IOIO exceptions from user-space
    
    Upstream commit: b9cb9c45583b911e0db71d09caa6b56469eb2bdf
    
    Check the IO permission bitmap (if present) before emulating IOIO #VC
    exceptions for user-space. These permissions are checked by hardware
    already before the #VC is raised, but due to the VC-handler decoding
    race it needs to be checked again in software.
    
    Fixes: 25189d08e516 ("x86/sev-es: Add support for handling IOIO exceptions")
    Reported-by: Tom Dohrmann <erbse.13@gmx.de>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Tom Dohrmann <erbse.13@gmx.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d78c5d8c23c3f0e24168ea98760016665bf92a79
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Thu Oct 5 11:06:36 2023 +0200

    x86/sev: Disable MMIO emulation from user mode
    
    Upstream commit: a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba
    
    A virt scenario can be constructed where MMIO memory can be user memory.
    When that happens, a race condition opens between when the hardware
    raises the #VC and when the #VC handler gets to emulate the instruction.
    
    If the MOVS is replaced with a MOVS accessing kernel memory in that
    small race window, then write to kernel memory happens as the access
    checks are not done at emulation time.
    
    Disable MMIO emulation in user mode temporarily until a sensible use
    case appears and justifies properly handling the race window.
    
    Fixes: 0118b604c2c9 ("x86/sev-es: Handle MMIO String Instructions")
    Reported-by: Tom Dohrmann <erbse.13@gmx.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Tom Dohrmann <erbse.13@gmx.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 459af3fb81e6e2f6cf8ea7b67f3b9062b0361f96
Author: Jim Mattson <jmattson@google.com>
Date:   Mon Sep 25 17:34:47 2023 +0000

    KVM: x86: Mask LVTPC when handling a PMI
    
    commit a16eb25b09c02a54c1c1b449d4b6cfa2cf3f013a upstream.
    
    Per the SDM, "When the local APIC handles a performance-monitoring
    counters interrupt, it automatically sets the mask flag in the LVT
    performance counter register."  Add this behavior to KVM's local APIC
    emulation.
    
    Failure to mask the LVTPC entry results in spurious PMIs, e.g. when
    running Linux as a guest, PMI handlers that do a "late_ack" spew a large
    number of "dazed and confused" spurious NMI warnings.
    
    Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Tested-by: Mingwei Zhang <mizhang@google.com>
    Signed-off-by: Mingwei Zhang <mizhang@google.com>
    Link: https://lore.kernel.org/r/20230925173448.3518223-3-mizhang@google.com
    [sean: massage changelog, correct Fixes]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cbac83549dd87da9ffa41a74e004f743285478e
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Oct 6 10:21:04 2023 +0200

    regmap: fix NULL deref on lookup
    
    commit c6df843348d6b71ea986266c12831cb60c2cf325 upstream.
    
    Not all regmaps have a name so make sure to check for that to avoid
    dereferencing a NULL pointer when dev_get_regmap() is used to lookup a
    named regmap.
    
    Fixes: e84861fec32d ("regmap: dev_get_regmap_match(): fix string comparison")
    Cc: stable@vger.kernel.org      # 5.8
    Cc: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231006082104.16707-1-johan+linaro@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c95fa5b20fe03609e0894656fa43c18045b5097e
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Oct 13 20:41:29 2023 +0200

    nfc: nci: fix possible NULL pointer dereference in send_acknowledge()
    
    commit 7937609cd387246aed994e81aa4fa951358fba41 upstream.
    
    Handle memory allocation failure from nci_skb_alloc() (calling
    alloc_skb()) to avoid possible NULL pointer dereference.
    
    Reported-by: 黄思聪 <huangsicong@iie.ac.cn>
    Fixes: 391d8a2da787 ("NFC: Add NCI over SPI receive")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20231013184129.18738-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e64f4c732cb129c73f04dee2213aeb8ecb1e27c
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Wed Oct 11 16:33:33 2023 -0700

    ice: reset first in crash dump kernels
    
    commit 0288c3e709e5fabd51e84715c5c798a02f43061a upstream.
    
    When the system boots into the crash dump kernel after a panic, the ice
    networking device may still have pending transactions that can cause errors
    or machine checks when the device is re-enabled. This can prevent the crash
    dump kernel from loading the driver or collecting the crash data.
    
    To avoid this issue, perform a function level reset (FLR) on the ice device
    via PCIe config space before enabling it on the crash kernel. This will
    clear any outstanding transactions and stop all queues and interrupts.
    Restore the config space after the FLR, otherwise it was found in testing
    that the driver wouldn't load successfully.
    
    The following sequence causes the original issue:
    - Load the ice driver with modprobe ice
    - Enable SR-IOV with 2 VFs: echo 2 > /sys/class/net/eth0/device/sriov_num_vfs
    - Trigger a crash with echo c > /proc/sysrq-trigger
    - Load the ice driver again (or let it load automatically) with modprobe ice
    - The system crashes again during pcim_enable_device()
    
    Fixes: 837f08fdecbe ("ice: Add basic driver framework for Intel(R) E800 Series")
    Reported-by: Vishal Agrawal <vagrawal@redhat.com>
    Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Link: https://lore.kernel.org/r/20231011233334.336092-3-jacob.e.keller@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95d68fdc71ba605825831b32a8d89c3901fc7c03
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Tue Oct 10 13:30:59 2023 -0700

    ice: fix over-shifted variable
    
    commit 242e34500a32631f85c2b4eb6cb42a368a39e54f upstream.
    
    Since the introduction of the ice driver the code has been
    double-shifting the RSS enabling field, because the define already has
    shifts in it and can't have the regular pattern of "a << shiftval &
    mask" applied.
    
    Most places in the code got it right, but one line was still wrong. Fix
    this one location for easy backports to stable. An in-progress patch
    fixes the defines to "standard" and will be applied as part of the
    regular -next process sometime after this one.
    
    Fixes: d76a60ba7afb ("ice: Add support for VLANs and offloads")
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://lore.kernel.org/r/20231010203101.406248-1-jacob.e.keller@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a56c436b4335537df91f8446adbd5c02a2b0ced6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 9 22:31:31 2023 +0200

    Bluetooth: avoid memcmp() out of bounds warning
    
    commit 9d1a3c74746428102d55371fbf74b484733937d9 upstream.
    
    bacmp() is a wrapper around memcpy(), which contain compile-time
    checks for buffer overflow. Since the hci_conn_request_evt() also calls
    bt_dev_dbg() with an implicit NULL pointer check, the compiler is now
    aware of a case where 'hdev' is NULL and treats this as meaning that
    zero bytes are available:
    
    In file included from net/bluetooth/hci_event.c:32:
    In function 'bacmp',
        inlined from 'hci_conn_request_evt' at net/bluetooth/hci_event.c:3276:7:
    include/net/bluetooth/bluetooth.h:364:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
      364 |         return memcmp(ba1, ba2, sizeof(bdaddr_t));
          |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Add another NULL pointer check before the bacmp() to ensure the compiler
    understands the code flow enough to not warn about it.  Since the patch
    that introduced the warning is marked for stable backports, this one
    should also go that way to avoid introducing build regressions.
    
    Fixes: 1ffc6f8cc332 ("Bluetooth: Reject connection with the device which has same BD_ADDR")
    Cc: Kees Cook <keescook@chromium.org>
    Cc: "Lee, Chun-Yi" <jlee@suse.com>
    Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e83d15e0ca2fdad203df5f8a0d5b47dd083eb2e
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Oct 5 14:12:19 2023 -0700

    Bluetooth: hci_event: Fix coding style
    
    commit 35d91d95a0cd61ebb90e0246dc917fd25e519b8c upstream.
    
    This fixes the following code style problem:
    
    ERROR: that open brace { should be on the previous line
    +       if (!bacmp(&hdev->bdaddr, &ev->bdaddr))
    +       {
    
    Fixes: 1ffc6f8cc332 ("Bluetooth: Reject connection with the device which has same BD_ADDR")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6878fa1730b8d9d59068b61593c63c7031f70e9
Author: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
Date:   Wed Sep 20 17:30:07 2023 +0200

    Bluetooth: vhci: Fix race when opening vhci device
    
    commit 92d4abd66f7080075793970fc8f241239e58a9e7 upstream.
    
    When the vhci device is opened in the two-step way, i.e.: open device
    then write a vendor packet with requested controller type, the device
    shall respond with a vendor packet which includes HCI index of created
    interface.
    
    When the virtual HCI is created, the host sends a reset request to the
    controller. This request is processed by the vhci_send_frame() function.
    However, this request is send by a different thread, so it might happen
    that this HCI request will be received before the vendor response is
    queued in the read queue. This results in the HCI vendor response and
    HCI reset request inversion in the read queue which leads to improper
    behavior of btvirt:
    
    > dmesg
    [1754256.640122] Bluetooth: MGMT ver 1.22
    [1754263.023806] Bluetooth: MGMT ver 1.22
    [1754265.043775] Bluetooth: hci1: Opcode 0x c03 failed: -110
    
    In order to synchronize vhci two-step open/setup process with virtual
    HCI initialization, this patch adds internal lock when queuing data in
    the vhci_send_frame() function.
    
    Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40a33a129d99639921ce00d274cca44ba282f1ac
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Wed Oct 4 20:42:24 2023 +0800

    Bluetooth: Fix a refcnt underflow problem for hci_conn
    
    commit c7f59461f5a78994613afc112cdd73688aef9076 upstream.
    
    Syzbot reports a warning as follows:
    
    WARNING: CPU: 1 PID: 26946 at net/bluetooth/hci_conn.c:619
    hci_conn_timeout+0x122/0x210 net/bluetooth/hci_conn.c:619
    ...
    Call Trace:
     <TASK>
     process_one_work+0x884/0x15c0 kernel/workqueue.c:2630
     process_scheduled_works kernel/workqueue.c:2703 [inline]
     worker_thread+0x8b9/0x1290 kernel/workqueue.c:2784
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
     </TASK>
    
    It is because the HCI_EV_SIMPLE_PAIR_COMPLETE event handler drops
    hci_conn directly without check Simple Pairing whether be enabled. But
    the Simple Pairing process can only be used if both sides have the
    support enabled in the host stack.
    
    Add hci_conn_ssp_enabled() for hci_conn in HCI_EV_IO_CAPA_REQUEST and
    HCI_EV_SIMPLE_PAIR_COMPLETE event handlers to fix the problem.
    
    Fixes: 0493684ed239 ("[Bluetooth] Disable disconnect timer during Simple Pairing")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab950561bca416489c0a5b0587a2a54acae234b1
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Sun Oct 1 16:59:58 2023 +0800

    Bluetooth: Reject connection with the device which has same BD_ADDR
    
    commit 1ffc6f8cc33268731fcf9629fc4438f6db1191fc upstream.
    
    This change is used to relieve CVE-2020-26555. The description of
    the CVE:
    
    Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
    1.0B through 5.2 may permit an unauthenticated nearby device to spoof
    the BD_ADDR of the peer device to complete pairing without knowledge
    of the PIN. [1]
    
    The detail of this attack is in IEEE paper:
    BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
    [2]
    
    It's a reflection attack. The paper mentioned that attacker can induce
    the attacked target to generate null link key (zero key) without PIN
    code. In BR/EDR, the key generation is actually handled in the controller
    which is below HCI.
    
    A condition of this attack is that attacker should change the
    BR_ADDR of his hacking device (Host B) to equal to the BR_ADDR with
    the target device being attacked (Host A).
    
    Thus, we reject the connection with device which has same BD_ADDR
    both on HCI_Create_Connection and HCI_Connection_Request to prevent
    the attack. A similar implementation also shows in btstack project.
    [3][4]
    
    Cc: stable@vger.kernel.org
    Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
    Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
    Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3523 [3]
    Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L7297 [4]
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e025a4528f41fed8fc16c9515211dba319b0fda
Author: Lee, Chun-Yi <jlee@suse.com>
Date:   Sun Oct 1 16:59:31 2023 +0800

    Bluetooth: hci_event: Ignore NULL link key
    
    commit 33155c4aae5260475def6f7438e4e35564f4f3ba upstream.
    
    This change is used to relieve CVE-2020-26555. The description of the
    CVE:
    
    Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
    1.0B through 5.2 may permit an unauthenticated nearby device to spoof
    the BD_ADDR of the peer device to complete pairing without knowledge
    of the PIN. [1]
    
    The detail of this attack is in IEEE paper:
    BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
    [2]
    
    It's a reflection attack. The paper mentioned that attacker can induce
    the attacked target to generate null link key (zero key) without PIN
    code. In BR/EDR, the key generation is actually handled in the controller
    which is below HCI.
    
    Thus, we can ignore null link key in the handler of "Link Key Notification
    event" to relieve the attack. A similar implementation also shows in
    btstack project. [3]
    
    v3: Drop the connection when null link key be detected.
    
    v2:
    - Used Link: tag instead of Closes:
    - Used bt_dev_dbg instead of BT_DBG
    - Added Fixes: tag
    
    Cc: stable@vger.kernel.org
    Fixes: 55ed8ca10f35 ("Bluetooth: Implement link key handling for the management interface")
    Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
    Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
    Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]
    Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 241f230324337ed5eae3846a554fb6d15169872c
Author: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Date:   Wed Aug 30 12:04:18 2023 +0200

    usb: hub: Guard against accesses to uninitialized BOS descriptors
    
    commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream.
    
    Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
    access fields inside udev->bos without checking if it was allocated and
    initialized. If usb_get_bos_descriptor() fails for whatever
    reason, udev->bos will be NULL and those accesses will result in a
    crash:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000018
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
    Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:hub_port_reset+0x193/0x788
    Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
    RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
    RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
    RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
    R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
    R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
    Call Trace:
    hub_event+0x73f/0x156e
    ? hub_activate+0x5b7/0x68f
    process_one_work+0x1a2/0x487
    worker_thread+0x11a/0x288
    kthread+0x13a/0x152
    ? process_one_work+0x487/0x487
    ? kthread_associate_blkcg+0x70/0x70
    ret_from_fork+0x1f/0x30
    
    Fall back to a default behavior if the BOS descriptor isn't accessible
    and skip all the functionalities that depend on it: LPM support checks,
    Super Speed capabilitiy checks, U1/U2 states setup.
    
    Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aec24b09630002c0b6b8cf46db8538e82d0e6f94
Author: Bagas Sanjaya <bagasdotme@gmail.com>
Date:   Wed Aug 24 10:58:04 2022 +0700

    Documentation: sysctl: align cells in second content column
    
    commit 1faa34672f8a17a3e155e74bde9648564e9480d6 upstream.
    
    Stephen Rothwell reported htmldocs warning when merging net-next tree:
    
    Documentation/admin-guide/sysctl/net.rst:37: WARNING: Malformed table.
    Text in column margin in table line 4.
    
    ========= =================== = ========== ==================
    Directory Content               Directory  Content
    ========= =================== = ========== ==================
    802       E802 protocol         mptcp     Multipath TCP
    appletalk Appletalk protocol    netfilter Network Filter
    ax25      AX25                  netrom     NET/ROM
    bridge    Bridging              rose      X.25 PLP layer
    core      General parameter     tipc      TIPC
    ethernet  Ethernet protocol     unix      Unix domain sockets
    ipv4      IP version 4          x25       X.25 protocol
    ipv6      IP version 6
    ========= =================== = ========== ==================
    
    The warning above is caused by cells in second "Content" column of
    /proc/sys/net subdirectory table which are in column margin.
    
    Align these cells against the column header to fix the warning.
    
    Link: https://lore.kernel.org/linux-next/20220823134905.57ed08d5@canb.auug.org.au/
    Fixes: 1202cdd665315c ("Remove DECnet support from kernel")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://lore.kernel.org/r/20220824035804.204322-1-bagasdotme@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f10690787d2cf691a10bf0e7a9be574d1fda6bbe
Author: Liam Mark <quic_lmark@quicinc.com>
Date:   Wed Jun 30 18:52:43 2021 -0700

    mm/memory_hotplug: rate limit page migration warnings
    
    commit 786dee864804f8e851cf0f258df2ccbb4ee03d80 upstream.
    
    When offlining memory the system can attempt to migrate a lot of pages, if
    there are problems with migration this can flood the logs.  Printing all
    the data hogs the CPU and cause some RT threads to run for a long time,
    which may have some bad consequences.
    
    Rate limit the page migration warnings in order to avoid this.
    
    Link: https://lkml.kernel.org/r/20210505140542.24935-1-georgi.djakov@linaro.org
    Signed-off-by: Liam Mark <lmark@codeaurora.org>
    Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
    Cc: David Hildenbrand <david@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <pjy@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf97ea76eac5072ee2307475b6dea9266a84bcc8
Author: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Date:   Sat Jan 21 12:39:42 2023 +0900

    lib/Kconfig.debug: do not enable DEBUG_PREEMPT by default
    
    commit cc6003916ed46d7a67d91ee32de0f9138047d55f upstream.
    
    In workloads where this_cpu operations are frequently performed,
    enabling DEBUG_PREEMPT may result in significant increase in
    runtime overhead due to frequent invocation of
    __this_cpu_preempt_check() function.
    
    This can be demonstrated through benchmarks such as hackbench where this
    configuration results in a 10% reduction in performance, primarily due to
    the added overhead within memcg charging path.
    
    Therefore, do not to enable DEBUG_PREEMPT by default and make users aware
    of its potential impact on performance in some workloads.
    
    hackbench-process-sockets
                          debug_preempt      no_debug_preempt
    Amean     1       0.4743 (   0.00%)      0.4295 *   9.45%*
    Amean     4       1.4191 (   0.00%)      1.2650 *  10.86%*
    Amean     7       2.2677 (   0.00%)      2.0094 *  11.39%*
    Amean     12      3.6821 (   0.00%)      3.2115 *  12.78%*
    Amean     21      6.6752 (   0.00%)      5.7956 *  13.18%*
    Amean     30      9.6646 (   0.00%)      8.5197 *  11.85%*
    Amean     48     15.3363 (   0.00%)     13.5559 *  11.61%*
    Amean     79     24.8603 (   0.00%)     22.0597 *  11.27%*
    Amean     96     30.1240 (   0.00%)     26.8073 *  11.01%*
    
    Link: https://lkml.kernel.org/r/20230121033942.350387-1-42.hyeyoo@gmail.com
    Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
    Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Acked-by: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Ben Segall <bsegall@google.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Dennis Zhou <dennis@kernel.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Valentin Schneider <vschneid@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Luiz Capitulino <luizcap@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c44b14469af07217074f6d83f08168a7aa438dd4
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Thu Jun 24 10:05:05 2021 +0200

    dev_forward_skb: do not scrub skb mark within the same name space
    
    commit ff70202b2d1ad522275c6aadc8c53519b6a22c57 upstream.
    
    The goal is to keep the mark during a bpf_redirect(), like it is done for
    legacy encapsulation / decapsulation, when there is no x-netns.
    This was initially done in commit 213dd74aee76 ("skbuff: Do not scrub skb
    mark within the same name space").
    
    When the call to skb_scrub_packet() was added in dev_forward_skb() (commit
    8b27f27797ca ("skb: allow skb_scrub_packet() to be used by tunnels")), the
    second argument (xnet) was set to true to force a call to skb_orphan(). At
    this time, the mark was always cleanned up by skb_scrub_packet(), whatever
    xnet value was.
    This call to skb_orphan() was removed later in commit
    9c4c325252c5 ("skbuff: preserve sock reference when scrubbing the skb.").
    But this 'true' stayed here without any real reason.
    
    Let's correctly set xnet in ____dev_forward_skb(), this function has access
    to the previous interface and to the new interface.
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db9aafa19547833240f58c2998aed7baf414dc82
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Oct 5 10:12:01 2023 +0900

    ravb: Fix use-after-free issue in ravb_tx_timeout_work()
    
    commit 3971442870713de527684398416970cf025b4f89 upstream.
    
    The ravb_stop() should call cancel_work_sync(). Otherwise,
    ravb_tx_timeout_work() is possible to use the freed priv after
    ravb_remove() was called like below:
    
    CPU0                    CPU1
                            ravb_tx_timeout()
    ravb_remove()
    unregister_netdev()
    free_netdev(ndev)
    // free priv
                            ravb_tx_timeout_work()
                            // use priv
    
    unregister_netdev() will call .ndo_stop() so that ravb_stop() is
    called. And, after phy_stop() is called, netif_carrier_off()
    is also called. So that .ndo_tx_timeout() will not be called
    after phy_stop().
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reported-by: Zheng Wang <zyytlz.wz@163.com>
    Closes: https://lore.kernel.org/netdev/20230725030026.1664873-1-zyytlz.wz@163.com/
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20231005011201.14368-3-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db375fa550c038c993473f715fb9239010ef5745
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Sep 8 16:31:39 2022 -0700

    RDMA/srp: Fix srp_abort()
    
    commit 6dbe4a8dead84de474483910b02ec9e6a10fc1a9 upstream.
    
    Fix the code for converting a SCSI command pointer into an SRP request
    pointer.
    
    Cc: Xiao Yang <yangx.jy@fujitsu.com>
    Fixes: ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20220908233139.3042628-1-bvanassche@acm.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f022576aa03c2385ea7f2b27ee5b331e43abf624
Author: yangx.jy@fujitsu.com <yangx.jy@fujitsu.com>
Date:   Wed Aug 31 08:16:29 2022 +0000

    RDMA/srp: Set scmnd->result only when scmnd is not NULL
    
    commit 12f35199a2c0551187edbf8eb01379f0598659fa upstream.
    
    This change fixes the following kernel NULL pointer dereference
    which is reproduced by blktests srp/007 occasionally.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000170
    PGD 0 P4D 0
    Oops: 0002 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
    Workqueue:  0x0 (kblockd)
    RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
    Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
    RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
    RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
    RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
    RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
    R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
    R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
    Call Trace:
     <IRQ>
     __ib_process_cq+0xb7/0x280 [ib_core]
     ib_poll_handler+0x2b/0x130 [ib_core]
     irq_poll_softirq+0x93/0x150
     __do_softirq+0xee/0x4b8
     irq_exit_rcu+0xf7/0x130
     sysvec_apic_timer_interrupt+0x8e/0xc0
     </IRQ>
    
    Fixes: ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent")
    Link: https://lore.kernel.org/r/20220831081626.18712-1-yangx.jy@fujitsu.com
    Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
    Acked-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 489818719a88e129f00719ca301379f7b720788a
Author: Ren Zhijie <renzhijie2@huawei.com>
Date:   Wed Oct 11 10:05:45 2023 +0000

    arm64: armv8_deprecated: fix unused-function error
    
    commit 223d3a0d30b6e9f979f5642e430e1753d3e29f89 upstream.
    
    If CONFIG_SWP_EMULATION is not set and
    CONFIG_CP15_BARRIER_EMULATION is not set,
    aarch64-linux-gnu complained about unused-function :
    
    arch/arm64/kernel/armv8_deprecated.c:67:21: error: ‘aarch32_check_condition’ defined but not used [-Werror=unused-function]
     static unsigned int aarch32_check_condition(u32 opcode, u32 psr)
                         ^~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    
    To fix this warning, modify aarch32_check_condition() with __maybe_unused.
    
    Fixes: 0c5f416219da ("arm64: armv8_deprecated: move aarch32 helper earlier")
    Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20221124022429.19024-1-renzhijie2@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da7603cedb7da6e2e7150054e838079e3fbf65a9
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:44 2023 +0000

    arm64: armv8_deprecated: rework deprected instruction handling
    
    commit 124c49b1b5d947b7180c5d6cbb09ddf76ea45ea2 upstream.
    
    Support for deprecated instructions can be enabled or disabled at
    runtime. To handle this, the code in armv8_deprecated.c registers and
    unregisters undef_hooks, and makes cross CPU calls to configure HW
    support. This is rather complicated, and the synchronization required to
    make this safe ends up serializing the handling of instructions which
    have been trapped.
    
    This patch simplifies the deprecated instruction handling by removing
    the dynamic registration and unregistration, and changing the trap
    handling code to determine whether a handler should be invoked. This
    removes the need for dynamic list management, and simplifies the locking
    requirements, making it possible to handle trapped instructions entirely
    in parallel.
    
    Where changing the emulation state requires a cross-call, this is
    serialized by locally disabling interrupts, ensuring that the CPU is not
    left in an inconsistent state.
    
    To simplify sysctl management, each insn_emulation is given a separate
    sysctl table, permitting these to be registered separately. The core
    sysctl code will iterate over all of these when walking sysfs.
    
    I've tested this with userspace programs which use each of the
    deprecated instructions, and I've concurrently modified the support
    level for each of the features back-and-forth between HW and emulated to
    check that there are no spurious SIGILLs sent to userspace when the
    support level is changed.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-10-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45a26d2a5394a29844ad530ef7a4ff3a81de88a3
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:43 2023 +0000

    arm64: armv8_deprecated: move aarch32 helper earlier
    
    commit 0c5f416219da3795dc8b33e5bb7865a6b3c4e55c upstream.
    
    Subsequent patches will rework the logic in armv8_deprecated.c.
    
    In preparation for subsequent changes, this patch moves some shared logic
    earlier in the file. This will make subsequent diffs simpler and easier to
    read.
    
    At the same time, drop the `__kprobes` annotation from
    aarch32_check_condition(), as this is only used for traps from compat
    userspace, and has no risk of recursion within kprobes. As this is the
    last kprobes annotation in armve8_deprecated.c, we no longer need to
    include <asm/kprobes.h>.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-9-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b6a7a9f6d944682237bd61bce7f590ebda6e716
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:42 2023 +0000

    arm64: armv8_deprecated move emulation functions
    
    commit 25eeac0cfe7c97ade1be07340e11e7143aab57a6 upstream.
    
    Subsequent patches will rework the logic in armv8_deprecated.c.
    
    In preparation for subsequent changes, this patch moves the emulation
    logic earlier in the file, and moves the infrastructure later in the
    file. This will make subsequent diffs simpler and easier to read.
    
    This is purely a move. There should be no functional change as a result
    of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-8-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2202536144bc37b6db8c6ebad09079108441e0c7
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:41 2023 +0000

    arm64: armv8_deprecated: fold ops into insn_emulation
    
    commit b4453cc8a7ebbd45436a8cd3ffeaa069ceac146f upstream.
    
    The code for emulating deprecated instructions has two related
    structures: struct insn_emulation_ops and struct insn_emulation, where
    each struct insn_emulation_ops is associated 1-1 with a struct
    insn_emulation.
    
    It would be simpler to combine the two into a single structure, removing
    the need for (unconditional) dynamic allocation at boot time, and
    simplifying some runtime pointer chasing.
    
    This patch merges the two structures together.
    
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-7-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5aa232345e4d18a40b3e0590c04e2f931903d46a
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:40 2023 +0000

    arm64: rework EL0 MRS emulation
    
    commit f5962add74b61f8ae31c6311f75ca35d7e1d2d8f upstream.
    
    On CPUs without FEAT_IDST, ID register emulation is slower than it needs
    to be, as all threads contend for the same lock to perform the
    emulation. This patch reworks the emulation to avoid this unnecessary
    contention.
    
    On CPUs with FEAT_IDST (which is mandatory from ARMv8.4 onwards), EL0
    accesses to ID registers result in a SYS trap, and emulation of these is
    handled with a sys64_hook. These hooks are statically allocated, and no
    locking is required to iterate through the hooks and perform the
    emulation, allowing emulation to occur in parallel with no contention.
    
    On CPUs without FEAT_IDST, EL0 accesses to ID registers result in an
    UNDEFINED exception, and emulation of these accesses is handled with an
    undef_hook. When an EL0 MRS instruction is trapped to EL1, the kernel
    finds the relevant handler by iterating through all of the undef_hooks,
    requiring undef_lock to be held during this lookup.
    
    This locking is only required to safely traverse the list of undef_hooks
    (as it can be concurrently modified), and the actual emulation of the
    MRS does not require any mutual exclusion. This locking is an
    unfortunate bottleneck, especially given that MRS emulation is enabled
    unconditionally and is never disabled.
    
    This patch reworks the non-FEAT_IDST MRS emulation logic so that it can
    be invoked directly from do_el0_undef(). This removes the bottleneck,
    allowing MRS traps to be handled entirely in parallel, and is a stepping
    stone to making all of the undef_hooks lock-free.
    
    I've tested this in a 64-vCPU VM on a 64-CPU ThunderX2 host, with a
    benchmark which spawns a number of threads which each try to read
    ID_AA64ISAR0_EL1 1000000 times. This is vastly more contention than will
    ever be seen in realistic usage, but clearly demonstrates the removal of
    the bottleneck:
    
      | Threads || Time (seconds)                       |
      |         || Before           || After            |
      |         || Real   | System  || Real   | System  |
      |---------++--------+---------++--------+---------|
      |       1 ||   0.29 |    0.20 ||   0.24 |    0.12 |
      |       2 ||   0.35 |    0.51 ||   0.23 |    0.27 |
      |       4 ||   1.08 |    3.87 ||   0.24 |    0.56 |
      |       8 ||   4.31 |   33.60 ||   0.24 |    1.11 |
      |      16 ||   9.47 |  149.39 ||   0.23 |    2.15 |
      |      32 ||  19.07 |  605.27 ||   0.24 |    4.38 |
      |      64 ||  65.40 | 3609.09 ||   0.33 |   11.27 |
    
    Aside from the speedup, there should be no functional change as a result
    of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-6-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e964971ff701c661936aa6103d51a895f32e24
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:39 2023 +0000

    arm64: factor insn read out of call_undef_hook()
    
    commit dbfbd87efa79575491af0ba1a87bf567eaea6cae upstream.
    
    Subsequent patches will rework EL0 UNDEF handling, removing the need for
    struct undef_hook and call_undef_hook. In preparation for those changes,
    this patch factors the logic for reading user instructions out of
    call_undef_hook() and into a new user_insn_read() helper, matching the
    style of the existing aarch64_insn_read() helper used for reading kernel
    instructions.
    
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-5-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0edde7fd1c3b5d0f52eb024ea8ef92e191d3dbe9
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:38 2023 +0000

    arm64: factor out EL1 SSBS emulation hook
    
    commit bff8f413c71ffc3cb679dbd9a5632b33af563f9f upstream.
    
    Currently call_undef_hook() is used to handle UNDEFINED exceptions from
    EL0 and EL1. As support for deprecated instructions may be enabled
    independently, the handlers for individual instructions are organised as
    a linked list of struct undef_hook which can be manipulated dynamically.
    As this can be manipulated dynamically, the list is protected with a
    raw_spinlock which must be acquired when handling UNDEFINED exceptions
    or when manipulating the list of handlers.
    
    This locking is unfortunate as it serialises handling of UNDEFINED
    exceptions, and requires RCU to be enabled for lockdep, requiring the
    use of RCU_NONIDLE() in resume path of cpu_suspend() since commit:
    
      a2c42bbabbe260b7 ("arm64: spectre: Prevent lockdep splat on v4 mitigation enable path")
    
    The list of UNDEFINED handlers largely consist of handlers for
    exceptions taken from EL0, and the only handler for exceptions taken
    from EL1 handles `MSR SSBS, #imm` on CPUs which feature PSTATE.SSBS but
    lack the corresponding MSR (Immediate) instruction. Other than this we
    never expect to take an UNDEFINED exception from EL1 in normal
    operation.
    
    This patch reworks do_el0_undef() to invoke the EL1 SSBS handler
    directly, relegating call_undef_hook() to only handle EL0 UNDEFs. This
    removes redundant work to iterate the list for EL1 UNDEFs, and removes
    the need for locking, permitting EL1 UNDEFs to be handled in parallel
    without contention.
    
    The RCU_NONIDLE() call in cpu_suspend() will be removed in a subsequent
    patch, as there are other potential issues with the use of
    instrumentable code and RCU in the CPU suspend code.
    
    I've tested this by forcing the detection of SSBS on a CPU that doesn't
    have it, and verifying that the try_emulate_el1_ssbs() callback is
    invoked.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-4-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a76df1ae1b3a6d1cc806066d48c6b95dc4335fa
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:37 2023 +0000

    arm64: split EL0/EL1 UNDEF handlers
    
    commit 61d64a376ea80f9097e7ea599bcd68671b836dc6 upstream.
    
    In general, exceptions taken from EL1 need to be handled separately from
    exceptions taken from EL0, as the logic to handle the two cases can be
    significantly divergent, and exceptions taken from EL1 typically have
    more stringent requirements on locking and instrumentation.
    
    Subsequent patches will rework the way EL1 UNDEFs are handled in order
    to address longstanding soundness issues with instrumentation and RCU.
    In preparation for that rework, this patch splits the existing
    do_undefinstr() handler into separate do_el0_undef() and do_el1_undef()
    handlers.
    
    Prior to this patch, do_undefinstr() was marked with NOKPROBE_SYMBOL(),
    preventing instrumentation via kprobes. However, do_undefinstr() invokes
    other code which can be instrumented, and:
    
    * For UNDEFINED exceptions taken from EL0, there is no risk of recursion
      within kprobes. Therefore it is safe for do_el0_undef to be
      instrumented with kprobes, and it does not need to be marked with
      NOKPROBE_SYMBOL().
    
    * For UNDEFINED exceptions taken from EL1, either:
    
      (a) The exception is has been taken when manipulating SSBS; these cases
          are limited and do not occur within code that can be invoked
          recursively via kprobes. Hence, in these cases instrumentation
          with kprobes is benign.
    
      (b) The exception has been taken for an unknown reason, as other than
          manipulating SSBS we do not expect to take UNDEFINED exceptions
          from EL1. Any handling of these exception is best-effort.
    
      ... and in either case, marking do_el1_undef() with NOKPROBE_SYMBOL()
      isn't sufficient to prevent recursion via kprobes as functions it
      calls (including die()) are instrumentable via kprobes.
    
      Hence, it's not worthwhile to mark do_el1_undef() with
      NOKPROBE_SYMBOL(). The same applies to do_el1_bti() and do_el1_fpac(),
      so their NOKPROBE_SYMBOL() annotations are also removed.
    
    Aside from the new instrumentability, there should be no functional
    change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-3-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a8d4cc303ef53b456af2660e0f5753cb3622d31
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:36 2023 +0000

    arm64: allow kprobes on EL0 handlers
    
    commit b3a0c010e900a9f89dcd99f10bd8f7538d21b0a9 upstream.
    
    Currently do_sysinstr() and do_cp15instr() are marked with
    NOKPROBE_SYMBOL(). However, these are only called for exceptions taken
    from EL0, and there is no risk of recursion in kprobes, so this is not
    necessary.
    
    Remove the NOKPROBE_SYMBOL() annotation, and rename the two functions to
    more clearly indicate that these are solely for exceptions taken from
    EL0, better matching the names used by the lower level entry points in
    entry-common.c.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Joey Gouly <joey.gouly@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20221019144123.612388-2-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 793ed958b62ad4831e03de51b3d23ad6eb23eea7
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:35 2023 +0000

    arm64: rework BTI exception handling
    
    commit 830a2a4d853f2c4a1e4606aa03341b7f273b0e9b upstream.
    
    If a BTI exception is taken from EL1, the entry code will treat this as
    an unhandled exception and will panic() the kernel. This is inconsistent
    with the way we handle FPAC exceptions, which have a dedicated handler
    and only necessarily kill the thread from which the exception was taken
    from, and we don't log all the information that could be relevant to
    debug the issue.
    
    The code in do_bti() has:
    
            BUG_ON(!user_mode(regs));
    
    ... and it seems like the intent was to call this for EL1 BTI
    exceptions, as with FPAC, but this was omitted due to an oversight.
    
    This patch adds separate EL0 and EL1 BTI exception handlers, with the
    latter calling die() directly to report the original context the BTI
    exception was taken from. This matches our handling of FPAC exceptions.
    
    Prior to this patch, a BTI failure is reported as:
    
    | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI
    | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00131-g7d937ff0221d-dirty #9
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 20400809 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)
    | pc : test_bti_callee+0x4/0x10
    | lr : test_bti_caller+0x1c/0x28
    | sp : ffff80000800bdf0
    | x29: ffff80000800bdf0 x28: 0000000000000000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: ffff80000a2b8000 x22: 0000000000000000 x21: 0000000000000000
    | x20: ffff8000099fa5b0 x19: ffff800009ff7000 x18: fffffbfffda37000
    | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000041a90000
    | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000
    | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000040000000
    | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000f83
    | x5 : ffff80000a2b6000 x4 : ffff0000028d0000 x3 : ffff800009f78378
    | x2 : 0000000000000000 x1 : 0000000040210000 x0 : ffff8000080257e4
    | Kernel panic - not syncing: Unhandled exception
    | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00131-g7d937ff0221d-dirty #9
    | Hardware name: linux,dummy-virt (DT)
    | Call trace:
    |  dump_backtrace.part.0+0xcc/0xe0
    |  show_stack+0x18/0x5c
    |  dump_stack_lvl+0x64/0x80
    |  dump_stack+0x18/0x34
    |  panic+0x170/0x360
    |  arm64_exit_nmi.isra.0+0x0/0x80
    |  el1h_64_sync_handler+0x64/0xd0
    |  el1h_64_sync+0x64/0x68
    |  test_bti_callee+0x4/0x10
    |  smp_cpus_done+0xb0/0xbc
    |  smp_init+0x7c/0x8c
    |  kernel_init_freeable+0x128/0x28c
    |  kernel_init+0x28/0x13c
    |  ret_from_fork+0x10/0x20
    
    With this patch applied, a BTI failure is reported as:
    
    | Internal error: Oops - BTI: 0000000034000002 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00132-g0ad98265d582-dirty #8
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 20400809 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)
    | pc : test_bti_callee+0x4/0x10
    | lr : test_bti_caller+0x1c/0x28
    | sp : ffff80000800bdf0
    | x29: ffff80000800bdf0 x28: 0000000000000000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: ffff80000a2b8000 x22: 0000000000000000 x21: 0000000000000000
    | x20: ffff8000099fa5b0 x19: ffff800009ff7000 x18: fffffbfffda37000
    | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000041a90000
    | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000
    | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000040000000
    | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000f83
    | x5 : ffff80000a2b6000 x4 : ffff0000028d0000 x3 : ffff800009f78378
    | x2 : 0000000000000000 x1 : 0000000040210000 x0 : ffff800008025804
    | Call trace:
    |  test_bti_callee+0x4/0x10
    |  smp_cpus_done+0xb0/0xbc
    |  smp_init+0x7c/0x8c
    |  kernel_init_freeable+0x128/0x28c
    |  kernel_init+0x28/0x13c
    |  ret_from_fork+0x10/0x20
    | Code: d50323bf d53cd040 d65f03c0 d503233f (d50323bf)
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220913101732.3925290-6-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9113333d7c7cf87219c9b919ed2bc10f7042c5be
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:34 2023 +0000

    arm64: rework FPAC exception handling
    
    commit a1fafa3b24a70461bbf3e5c0770893feb0a49292 upstream.
    
    If an FPAC exception is taken from EL1, the entry code will call
    do_ptrauth_fault(), where due to:
    
            BUG_ON(!user_mode(regs))
    
    ... the kernel will report a problem within do_ptrauth_fault() rather
    than reporting the original context the FPAC exception was taken from.
    The pt_regs and ESR value reported will be from within
    do_ptrauth_fault() and the code dump will be for the BRK in BUG_ON(),
    which isn't sufficient to debug the cause of the original exception.
    
    This patch makes the reporting better by having separate EL0 and EL1
    FPAC exception handlers, with the latter calling die() directly to
    report the original context the FPAC exception was taken from.
    
    Note that we only need to prevent kprobes of the EL1 FPAC handler, since
    the EL0 FPAC handler cannot be called recursively.
    
    For consistency with do_el0_svc*(), I've named the split functions
    do_el{0,1}_fpac() rather than do_el{0,1}_ptrauth_fault(). I've also
    clarified the comment to not imply there are casues other than FPAC
    exceptions.
    
    Prior to this patch FPAC exceptions are reported as:
    
    | kernel BUG at arch/arm64/kernel/traps.c:517!
    | Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00130-g9c8a180a1cdf-dirty #12
    | Hardware name: FVP Base RevC (DT)
    | pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : do_ptrauth_fault+0x3c/0x40
    | lr : el1_fpac+0x34/0x54
    | sp : ffff80000a3bbc80
    | x29: ffff80000a3bbc80 x28: ffff0008001d8000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: 0000000020400009 x22: ffff800008f70fa4 x21: ffff80000a3bbe00
    | x20: 0000000072000000 x19: ffff80000a3bbcb0 x18: fffffbfffda37000
    | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000081a90000
    | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000
    | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000080000000
    | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000783
    | x5 : ffff80000a3bbcb0 x4 : ffff0008001d8000 x3 : 0000000072000000
    | x2 : 0000000000000000 x1 : 0000000020400009 x0 : ffff80000a3bbcb0
    | Call trace:
    |  do_ptrauth_fault+0x3c/0x40
    |  el1h_64_sync_handler+0xc4/0xd0
    |  el1h_64_sync+0x64/0x68
    |  test_pac+0x8/0x10
    |  smp_init+0x7c/0x8c
    |  kernel_init_freeable+0x128/0x28c
    |  kernel_init+0x28/0x13c
    |  ret_from_fork+0x10/0x20
    | Code: 97fffe5e a8c17bfd d50323bf d65f03c0 (d4210000)
    
    With this patch applied FPAC exceptions are reported as:
    
    | Internal error: Oops - FPAC: 0000000072000000 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00132-g78846e1c4757-dirty #11
    | Hardware name: FVP Base RevC (DT)
    | pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : test_pac+0x8/0x10
    | lr : 0x0
    | sp : ffff80000a3bbe00
    | x29: ffff80000a3bbe00 x28: 0000000000000000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: ffff80000a2c8000 x22: 0000000000000000 x21: 0000000000000000
    | x20: ffff8000099fa5b0 x19: ffff80000a007000 x18: fffffbfffda37000
    | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000081a90000
    | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000
    | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000080000000
    | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000783
    | x5 : ffff80000a2c6000 x4 : ffff0008001d8000 x3 : ffff800009f88378
    | x2 : 0000000000000000 x1 : 0000000080210000 x0 : ffff000001a90000
    | Call trace:
    |  test_pac+0x8/0x10
    |  smp_init+0x7c/0x8c
    |  kernel_init_freeable+0x128/0x28c
    |  kernel_init+0x28/0x13c
    |  ret_from_fork+0x10/0x20
    | Code: d50323bf d65f03c0 d503233f aa1f03fe (d50323bf)
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220913101732.3925290-5-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8d7c8484ff762bbdfde26e838d3bc451817454d
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:33 2023 +0000

    arm64: consistently pass ESR_ELx to die()
    
    commit 0f2cb928a1547ae8f89e80a4b8df2c6c02ae5f96 upstream.
    
    Currently, bug_handler() and kasan_handler() call die() with '0' as the
    'err' value, whereas die_kernel_fault() passes the ESR_ELx value.
    
    For consistency, this patch ensures we always pass the ESR_ELx value to
    die(). As this is only called for exceptions taken from kernel mode,
    there should be no user-visible change as a result of this patch.
    
    For UNDEFINED exceptions, I've had to modify do_undefinstr() and its
    callers to pass the ESR_ELx value. In all cases the ESR_ELx value had
    already been read and was available.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20220913101732.3925290-4-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 004bdab6edc70aa5bd0e61573bacaee7857c5790
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:32 2023 +0000

    arm64: die(): pass 'err' as long
    
    commit 18906ff9af6517c20763ed63dab602a4150794f7 upstream.
    
    Recently, we reworked a lot of code to consistentlt pass ESR_ELx as a
    64-bit quantity. However, we missed that this can be passed into die()
    and __die() as the 'err' parameter where it is truncated to a 32-bit
    int.
    
    As notify_die() already takes 'err' as a long, this patch changes die()
    and __die() to also take 'err' as a long, ensuring that the full value
    of ESR_ELx is retained.
    
    At the same time, die() is updated to consistently log 'err' as a
    zero-padded 64-bit quantity.
    
    Subsequent patches will pass the ESR_ELx value to die() for a number of
    exceptions.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220913101732.3925290-3-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 835cb1f78d746dc668997f723c804441c36e8540
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Oct 11 10:05:31 2023 +0000

    arm64: report EL1 UNDEFs better
    
    commit b502c87d2a26c349acbc231ff2acd6f17147926b upstream.
    
    If an UNDEFINED exception is taken from EL1, and do_undefinstr() doesn't
    find any suitable undef_hook, it will call:
    
            BUG_ON(!user_mode(regs))
    
    ... and the kernel will report a failure witin do_undefinstr() rather
    than reporting the original context that the UNDEFINED exception was
    taken from. The pt_regs and ESR value reported within the BUG() handler
    will be from within do_undefinstr() and the code dump will be for the
    BRK in BUG_ON(), which isn't sufficient to debug the cause of the
    original exception.
    
    This patch makes the reporting better by having do_undefinstr() call
    die() directly in this case to report the original context from which
    the UNDEFINED exception was taken.
    
    Prior to this patch, an undefined instruction is reported as:
    
    | kernel BUG at arch/arm64/kernel/traps.c:497!
    | Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc3-00127-geff044f1b04e-dirty #3
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : do_undefinstr+0x28c/0x2ac
    | lr : do_undefinstr+0x298/0x2ac
    | sp : ffff800009f63bc0
    | x29: ffff800009f63bc0 x28: ffff800009f73c00 x27: ffff800009644a70
    | x26: ffff8000096778a8 x25: 0000000000000040 x24: 0000000000000000
    | x23: 00000000800000c5 x22: ffff800009894060 x21: ffff800009f63d90
    | x20: 0000000000000000 x19: ffff800009f63c40 x18: 0000000000000006
    | x17: 0000000000403000 x16: 00000000bfbfd000 x15: ffff800009f63830
    | x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000019
    | x11: 0101010101010101 x10: 0000000000161b98 x9 : 0000000000000000
    | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
    | x5 : ffff800009f761d0 x4 : 0000000000000000 x3 : ffff80000a2b80f8
    | x2 : 0000000000000000 x1 : ffff800009f73c00 x0 : 00000000800000c5
    | Call trace:
    |  do_undefinstr+0x28c/0x2ac
    |  el1_undef+0x2c/0x4c
    |  el1h_64_sync_handler+0x84/0xd0
    |  el1h_64_sync+0x64/0x68
    |  setup_arch+0x550/0x598
    |  start_kernel+0x88/0x6ac
    |  __primary_switched+0xb8/0xc0
    | Code: 17ffff95 a9425bf5 17ffffb8 a9025bf5 (d4210000)
    
    With this patch applied, an undefined instruction is reported as:
    
    | Internal error: Oops - Undefined instruction: 0 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc3-00128-gf27cfcc80e52-dirty #5
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : setup_arch+0x550/0x598
    | lr : setup_arch+0x50c/0x598
    | sp : ffff800009f63d90
    | x29: ffff800009f63d90 x28: 0000000081000200 x27: ffff800009644a70
    | x26: ffff8000096778c8 x25: 0000000000000040 x24: 0000000000000000
    | x23: 0000000000000100 x22: ffff800009f69a58 x21: ffff80000a2b80b8
    | x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000006
    | x17: 0000000000403000 x16: 00000000bfbfd000 x15: ffff800009f63830
    | x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000019
    | x11: 0101010101010101 x10: 0000000000161b98 x9 : 0000000000000000
    | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
    | x5 : 0000000000000008 x4 : 0000000000000010 x3 : 0000000000000000
    | x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
    | Call trace:
    |  setup_arch+0x550/0x598
    |  start_kernel+0x88/0x6ac
    |  __primary_switched+0xb8/0xc0
    | Code: b4000080 90ffed80 912ac000 97db745f (00000000)
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Cc: Alexandru Elisei <alexandru.elisei@arm.com>
    Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
    Cc: James Morse <james.morse@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Link: https://lore.kernel.org/r/20220913101732.3925290-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6788b10620ca6e98575d1e06e72a8974aad7657e
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Thu Oct 12 13:04:24 2023 +0300

    x86/alternatives: Disable KASAN in apply_alternatives()
    
    commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream.
    
    Fei has reported that KASAN triggers during apply_alternatives() on
    a 5-level paging machine:
    
            BUG: KASAN: out-of-bounds in rcu_is_watching()
            Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
            ...
            __asan_load4()
            rcu_is_watching()
            trace_hardirqs_on()
            text_poke_early()
            apply_alternatives()
            ...
    
    On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
    gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
    __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
    
    KASAN gets confused when apply_alternatives() patches the
    KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
    static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
    
    Fix it for real by disabling KASAN while the kernel is patching alternatives.
    
    [ mingo: updated the changelog ]
    
    Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")
    Reported-by: Fei Yang <fei.yang@intel.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231012100424.1456-1-kirill.shutemov@linux.intel.com
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba4b377210968f4385ab41cc1a86db073fce9c22
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Sep 25 20:31:16 2023 +0200

    powerpc/64e: Fix wrong test in __ptep_test_and_clear_young()
    
    [ Upstream commit 5ea0bbaa32e8f54e9a57cfee4a3b8769b80be0d2 ]
    
    Commit 45201c879469 ("powerpc/nohash: Remove hash related code from
    nohash headers.") replaced:
    
      if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0)
            return 0;
    
    By:
    
      if (pte_young(*ptep))
            return 0;
    
    But it should be:
    
      if (!pte_young(*ptep))
            return 0;
    
    Fix it.
    
    Fixes: 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/8bb7f06494e21adada724ede47a4c3d97e879d40.1695659959.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dadb86fba67f7f9a41d869bce5c25d1c156c2754
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Sep 25 20:31:15 2023 +0200

    powerpc/8xx: Fix pte_access_permitted() for PAGE_NONE
    
    [ Upstream commit 5d9cea8a552ee122e21fbd5a3c5d4eb85f648e06 ]
    
    On 8xx, PAGE_NONE is handled by setting _PAGE_NA instead of clearing
    _PAGE_USER.
    
    But then pte_user() returns 1 also for PAGE_NONE.
    
    As _PAGE_NA prevent reads, add a specific version of pte_read()
    that returns 0 when _PAGE_NA is set instead of always returning 1.
    
    Fixes: 351750331fc1 ("powerpc/mm: Introduce _PAGE_NA")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/57bcfbe578e43123f9ed73e040229b80f1ad56ec.1695659959.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 288a0593c7985ba9e0dab6c63e49ed00cff34d47
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Aug 6 11:25:11 2023 +0800

    dmaengine: mediatek: Fix deadlock caused by synchronize_irq()
    
    [ Upstream commit 01f1ae2733e2bb4de92fefcea5fda847d92aede1 ]
    
    The synchronize_irq(c->irq) will not return until the IRQ handler
    mtk_uart_apdma_irq_handler() is completed. If the synchronize_irq()
    holds a spin_lock and waits the IRQ handler to complete, but the
    IRQ handler also needs the same spin_lock. The deadlock will happen.
    The process is shown below:
    
              cpu0                        cpu1
    mtk_uart_apdma_device_pause() | mtk_uart_apdma_irq_handler()
      spin_lock_irqsave()         |
                                  |   spin_lock_irqsave()
      //hold the lock to wait     |
      synchronize_irq()           |
    
    This patch reorders the synchronize_irq(c->irq) outside the spin_lock
    in order to mitigate the bug.
    
    Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Eugen Hristev <eugen.hristev@collabora.com>
    Link: https://lore.kernel.org/r/20230806032511.45263-1-duoming@zju.edu.cn
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17c653d4913bbc50d284aa96cf12bfc63e41ee5c
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Wed Sep 27 16:28:58 2023 +0530

    usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call
    
    commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream.
    
    When NCM is used with hosts like Windows PC, it is observed that there are
    multiple NTB's contained in one usb request giveback. Since the driver
    unwraps the obtained request data assuming only one NTB is present, we
    loose the subsequent NTB's present resulting in data loss.
    
    Fix this by checking the parsed block length with the obtained data
    length in usb request and continue parsing after the last byte of current
    NTB.
    
    Cc: stable@vger.kernel.org
    Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20230927105858.12950-1-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a906f2eb675c8a1101ea1a901dc7c9f4d26459a8
Author: Piyush Mehta <piyush.mehta@amd.com>
Date:   Fri Sep 29 17:45:14 2023 +0530

    usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
    
    commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream.
    
    For ARM processor, unaligned access to device memory is not allowed.
    Method memcpy does not take care of alignment.
    
    USB detection failure with the unalingned address of memory, with
    below kernel crash. To fix the unalingned address kernel panic,
    replace memcpy with memcpy_toio method.
    
    Kernel crash:
    Unable to handle kernel paging request at virtual address ffff80000c05008a
    Mem abort info:
      ESR = 0x96000061
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x21: alignment fault
    Data abort info:
      ISV = 0, ISS = 0x00000061
      CM = 0, WnR = 1
    swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000
    [ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003,
    pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713
    Internal error: Oops: 96000061 [#1] SMP
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
    Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
    pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __memcpy+0x30/0x260
    lr : __xudc_ep0_queue+0xf0/0x110
    sp : ffff800008003d00
    x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
    x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
    x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
    x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
    x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
    x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
    x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0
    x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112
    x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80
    x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088
    Call trace:
     __memcpy+0x30/0x260
     xudc_ep0_queue+0x3c/0x60
     usb_ep_queue+0x38/0x44
     composite_ep0_queue.constprop.0+0x2c/0xc0
     composite_setup+0x8d0/0x185c
     configfs_composite_setup+0x74/0xb0
     xudc_irq+0x570/0xa40
     __handle_irq_event_percpu+0x58/0x170
     handle_irq_event+0x60/0x120
     handle_fasteoi_irq+0xc0/0x220
     handle_domain_irq+0x60/0x90
     gic_handle_irq+0x74/0xa0
     call_on_irq_stack+0x2c/0x60
     do_interrupt_handler+0x54/0x60
     el1_interrupt+0x30/0x50
     el1h_64_irq_handler+0x18/0x24
     el1h_64_irq+0x78/0x7c
     arch_cpu_idle+0x18/0x2c
     do_idle+0xdc/0x15c
     cpu_startup_entry+0x28/0x60
     rest_init+0xc8/0xe0
     arch_call_rest_init+0x10/0x1c
     start_kernel+0x694/0x6d4
     __primary_switched+0xa4/0xac
    
    Fixes: 1f7c51660034 ("usb: gadget: Add xilinx usb2 device support")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
    Link: https://lore.kernel.org/r/20230929121514.13475-1-piyush.mehta@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7decb6515138f74840b31715111d8de025edeb93
Author: Dharma Balasubiramani <dharma.b@microchip.com>
Date:   Tue Sep 5 15:38:35 2023 +0530

    counter: microchip-tcb-capture: Fix the use of internal GCLK logic
    
    commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.
    
    As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should
    be set to 0 while using the internal GCLK (TIMER_CLOCK1).
    
    Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
    Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
    Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com
    Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a177771bff638a17010f5fb7c0628ed39fbb15c0
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Sep 20 11:09:10 2023 -0700

    pinctrl: avoid unsafe code pattern in find_pinctrl()
    
    commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream.
    
    The code in find_pinctrl() takes a mutex and traverses a list of pinctrl
    structures. Later the caller bumps up reference count on the found
    structure. Such pattern is not safe as pinctrl that was found may get
    deleted before the caller gets around to increasing the reference count.
    
    Fix this by taking the reference count in find_pinctrl(), while it still
    holds the mutex.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/ZQs1RgTKg6VJqmPs@google.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a4a8280402453489ca0dc67ced4db9feb87b4a3
Author: Michal Koutný <mkoutny@suse.com>
Date:   Mon Oct 9 15:58:11 2023 +0200

    cgroup: Remove duplicates in cgroup v1 tasks file
    
    commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream.
    
    One PID may appear multiple times in a preloaded pidlist.
    (Possibly due to PID recycling but we have reports of the same
    task_struct appearing with different PIDs, thus possibly involving
    transfer of PID via de_thread().)
    
    Because v1 seq_file iterator uses PIDs as position, it leads to
    a message:
    > seq_file: buggy .next function kernfs_seq_next did not update position index
    
    Conservative and quick fix consists of removing duplicates from `tasks`
    file (as opposed to removing pidlists altogether). It doesn't affect
    correctness (it's sufficient to show a PID once), performance impact
    would be hidden by unconditional sorting of the pidlist already in place
    (asymptotically).
    
    Link: https://lore.kernel.org/r/20230823174804.23632-1-mkoutny@suse.com/
    Suggested-by: Firo Yang <firo.yang@suse.com>
    Signed-off-by: Michal Koutný <mkoutny@suse.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da7ce52a2f6c468946195b116615297d3d113a27
Author: Rijo Thomas <Rijo-john.Thomas@amd.com>
Date:   Fri Sep 29 12:30:24 2023 +0530

    tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
    
    commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream.
    
    There is a potential race condition in amdtee_close_session that may
    cause use-after-free in amdtee_open_session. For instance, if a session
    has refcount == 1, and one thread tries to free this session via:
    
        kref_put(&sess->refcount, destroy_session);
    
    the reference count will get decremented, and the next step would be to
    call destroy_session(). However, if in another thread,
    amdtee_open_session() is called before destroy_session() has completed
    execution, alloc_session() may return 'sess' that will be freed up
    later in destroy_session() leading to use-after-free in
    amdtee_open_session.
    
    To fix this issue, treat decrement of sess->refcount and removal of
    'sess' from session list in destroy_session() as a critical section, so
    that it is executed atomically.
    
    Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
    Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ea0231dd1b22e0038a64811475f7f28eee24999
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Oct 4 07:18:31 2023 -0700

    Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case
    
    commit 423622a90abb243944d1517b9f57db53729e45c4 upstream.
    
    Add a special case for gpio_count == 1 && gpio_int_idx == 0 to
    goodix_add_acpi_gpio_mappings().
    
    It seems that on newer x86/ACPI devices the reset and irq GPIOs are no
    longer listed as GPIO resources instead there is only 1 GpioInt resource
    and _PS0 does the whole reset sequence for us.
    
    This means that we must call acpi_device_fix_up_power() on these devices
    to ensure that the chip is reset before we try to use it.
    
    This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call
    acpi_device_fix_up_power() in some cases") by adding a call to
    acpi_device_fix_up_power() to the generic "Unexpected ACPI resources"
    catch all.
    
    But it turns out that this case on some hw needs some more special
    handling. Specifically the firmware may bootup with the IRQ pin in
    output mode. The reset sequence from ACPI _PS0 (executed by
    acpi_device_fix_up_power()) should put the pin in input mode,
    but the GPIO subsystem has cached the direction at bootup, causing
    request_irq() to fail due to gpiochip_lock_as_irq() failure:
    
    [    9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0
    [    9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060
    [    9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8
    [    9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
    [    9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ
    [    9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio
    [    9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5
    
    Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0
    which adds an ACPI GPIO lookup table for the int GPIO even though we cannot
    use it for reset purposes (as there is no reset GPIO).
    
    Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call
    succeed, which will explicitly set the direction to input fixing the issue.
    
    Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since
    there is only 1 GPIO in the ACPI resources the reset entry in that
    lookup table will amount to a no-op.
    
    Reported-and-tested-by: Michael Smith <1973.mjsmith@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39fb79407e595710c1c2ea6504df3e32f75e33ee
Author: Szilard Fabian <szfabian@bluemarch.art>
Date:   Wed Oct 4 05:47:01 2023 -0700

    Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table
    
    commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 upstream.
    
    In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411
    refuses to work and it's not possible to type for example a dm-crypt
    passphrase without the help of an external keyboard.
    
    i8042.nomux kernel parameter resolves this issue but using that a PS/2
    mouse is detected. This input device is unused even when the i2c-hid-acpi
    kernel module is blacklisted making the integrated ELAN touchpad
    (04F3:308A) not working at all.
    
    Since the integrated touchpad is managed by the i2c_designware input
    driver in the Linux kernel and you can't find a PS/2 mouse port on the
    computer I think it's safe to not use the PS/2 mouse port at all.
    
    Signed-off-by: Szilard Fabian <szfabian@bluemarch.art>
    Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.art
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d862a3dff7e0dd0f1500131725e49ce8b58718b
Author: Matthias Berndt <matthias_berndt@gmx.de>
Date:   Fri Oct 13 15:04:36 2023 -0700

    Input: xpad - add PXN V900 support
    
    commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream.
    
    Add VID and PID to the xpad_device table to allow driver to use the PXN
    V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode.
    
    Signed-off-by: Matthias Berndt <matthias_berndt@gmx.de>
    Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8ea649fc35fba0b7b0b3243e6ed3203a0a27bad
Author: Jeffery Miller <jefferymiller@google.com>
Date:   Fri Oct 13 15:23:49 2023 -0700

    Input: psmouse - fix fast_reconnect function for PS/2 mode
    
    commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream.
    
    When the SMBus connection is attempted psmouse_smbus_init() sets
    the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus
    initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will
    fallback to PS/2 mode, replacing the psmouse private data. This can cause
    issues on resume, since psmouse_smbus_reconnect() expects to find an
    instance of struct psmouse_smbus_dev in psmouse->private.
    
    The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add
    delay when deactivating for SMBus mode") psmouse_smbus_reconnect()
    started attempting to use more of the data structure. The commit was
    since reverted, not because it was at fault, but because there was found
    a better way of doing what it was attempting to do.
    
    Fix the problem by resetting the fast_reconnect pointer in psmouse
    structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2
    mode is used.
    
    Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
    Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
    Signed-off-by: Jeffery Miller <jefferymiller@google.com>
    Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate")
    Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd2fbfd8b922b7fdd50732e47d797754ab59cb06
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Fri Oct 13 20:11:33 2023 -0700

    Input: powermate - fix use-after-free in powermate_config_complete
    
    commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream.
    
    syzbot has found a use-after-free bug [1] in the powermate driver. This
    happens when the device is disconnected, which leads to a memory free from
    the powermate_device struct.  When an asynchronous control message
    completes after the kfree and its callback is invoked, the lock does not
    exist anymore and hence the bug.
    
    Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
    device disconnection.
    
    [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
    
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27b6c809d3937275576c297a72290f618db3f45b
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Oct 7 11:52:39 2023 +0300

    ceph: fix type promotion bug on 32bit systems
    
    commit 07bb00ef00ace88dd6f695fadbba76565756e55c upstream.
    
    In this code "ret" is type long and "src_objlen" is unsigned int.  The
    problem is that on 32bit systems, when we do the comparison signed longs
    are type promoted to unsigned int.  So negative error codes from
    do_splice_direct() are treated as success instead of failure.
    
    Cc: stable@vger.kernel.org
    Fixes: 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b2bf63671ccbb68b5ebc94e808a44cced79cb27
Author: Xiubo Li <xiubli@redhat.com>
Date:   Wed Sep 6 14:22:07 2023 +0800

    ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
    
    commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream.
    
    When truncating the inode the MDS will acquire the xlock for the
    ifile Locker, which will revoke the 'Frwsxl' caps from the clients.
    But when the client just releases and flushes the 'Fw' caps to MDS,
    for exmaple, and once the MDS receives the caps flushing msg it
    just thought the revocation has finished. Then the MDS will continue
    truncating the inode and then issued the truncate notification to
    all the clients. While just before the clients receives the cap
    flushing ack they receive the truncation notification, the clients
    will detecte that the 'issued | dirty' is still holding the 'Fw'
    caps.
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/56693
    Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex")
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Milind Changire <mchangir@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62f6d24f2e7d6dee31eca8027543f264a4352a31
Author: Jordan Rife <jrife@google.com>
Date:   Wed Oct 4 18:38:27 2023 -0500

    libceph: use kernel_connect()
    
    commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.
    
    Direct calls to ops->connect() can overwrite the address parameter when
    used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
    kernel_connect() ensure that callers are insulated from such side
    effects. This patch wraps the direct call to ops->connect() with
    kernel_connect() to prevent unexpected changes to the address passed to
    ceph_tcp_connect().
    
    This change was originally part of a larger patch targeting the net tree
    addressing all instances of unprotected calls to ops->connect()
    throughout the kernel, but this change was split up into several patches
    targeting various trees.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
    Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
    Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
    Signed-off-by: Jordan Rife <jrife@google.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5850eb4df42294022a950e5e17e62b5911997c31
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Aug 22 16:36:18 2023 +0300

    thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding
    
    commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.
    
    Marek reported that when BlackMagic UltraStudio device is connected the
    kernel repeatedly tries to enable lane bonding without success making
    the device non-functional. It looks like the device does not have lane 1
    connected at all so even though it is enabled we should not try to bond
    the lanes. For this reason check that lane 1 is in fact CL0 (connected,
    active) before attempting to bond the lanes.
    
    Reported-by: Marek Å anta <teslan223@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 008ba1a5ada58f0e4cdfaeff3eed88a443296ab0
Author: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
Date:   Wed Sep 6 11:49:26 2023 +0000

    mcb: remove is_added flag from mcb_device struct
    
    commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream.
    
    When calling mcb_bus_add_devices(), both mcb devices and the mcb
    bus will attempt to attach a device to a driver because they share
    the same bus_type. This causes an issue when trying to cast the
    container of the device to mcb_device struct using to_mcb_device(),
    leading to a wrong cast when the mcb_bus is added. A crash occurs
    when freing the ida resources as the bus numbering of mcb_bus gets
    confused with the is_added flag on the mcb_device struct.
    
    The only reason for this cast was to keep an is_added flag on the
    mcb_device struct that does not seem necessary. The function
    device_attach() handles already bound devices and the mcb subsystem
    does nothing special with this is_added flag so remove it completely.
    
    Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
    Co-developed-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
    Signed-off-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
    Link: https://lore.kernel.org/r/20230906114901.63174-2-JoseJavier.Rodriguez@duagon.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec93456c0289850235cee83a91c6c5567d607a55
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Sat Oct 7 12:57:02 2023 +0200

    x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs
    
    commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.
    
    Fix erratum #1485 on Zen4 parts where running with STIBP disabled can
    cause an #UD exception. The performance impact of the fix is negligible.
    
    Reported-by: René Rebe <rene@exactcode.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: René Rebe <rene@exactcode.de>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/D99589F4-BC5D-430B-87B2-72C20370CF57@exactcode.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b608f4aedc0eb4e4eb78ebb6978f3f7d0c368797
Author: Alexander Zangerl <az@breathe-safe.com>
Date:   Wed Sep 20 10:01:10 2023 +1000

    iio: pressure: ms5611: ms5611_prom_is_valid false negative bug
    
    commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream.
    
    The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips
    with "PROM integrity check failed" because it doesn't accept a prom crc
    value of zero as legitimate.
    
    According to the datasheet for this chip (and the manufacturer's
    application note about the PROM CRC), none of the possible values for the
    CRC are excluded - but the current code in ms5611_prom_is_valid() ends with
    
    return crc_orig != 0x0000 && crc == crc_orig
    
    Discussed with the driver author (Tomasz Duszynski) and he indicated that
    at that time (2015) he was dealing with some faulty chip samples which
    returned blank data under some circumstances and/or followed example code
    which indicated CRC zero being bad.
    
    As far as I can tell this exception should not be applied anymore; We've
    got a few hundred custom boards here with this chip where large numbers
    of the prom have a legitimate CRC value 0, and do work fine, but which the
    current driver code wrongly rejects.
    
    Signed-off-by: Alexander Zangerl <az@breathe-safe.com>
    Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor")
    Link: https://lore.kernel.org/r/2535-1695168070.831792@Ze3y.dhYT.s3fx
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02388eaf3a15ec4e8dc01bd59842c2b104d31bed
Author: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
Date:   Tue Aug 29 13:02:22 2023 -0500

    iio: pressure: dps310: Adjust Timeout Settings
    
    commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream.
    
    The DPS310 sensor chip has been encountering intermittent errors while
    reading the sensor device across various system designs. This issue causes
    the chip to become "stuck," preventing the indication of "ready" status
    for pressure and temperature measurements in the MEAS_CFG register.
    
    To address this issue, this commit fixes the timeout settings to improve
    sensor stability:
    - After sending a reset command to the chip, the timeout has been extended
      from 2.5 ms to 15 ms, aligning with the DPS310 specification.
    - The read timeout value of the MEAS_CFG register has been adjusted from
      20ms to 30ms to match the specification.
    
    Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
    Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout")
    Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2abd2cffa1b8a80f32bef2539fc129b21fd6e846
Author: Phil Elwell <phil@raspberrypi.com>
Date:   Fri Aug 11 16:58:29 2023 +0100

    iio: pressure: bmp280: Fix NULL pointer exception
    
    commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream.
    
    The bmp085 EOC IRQ support is optional, but the driver's common probe
    function queries the IRQ properties whether or not it exists, which
    can trigger a NULL pointer exception. Avoid any exception by making
    the query conditional on the possession of a valid IRQ.
    
    Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
    Signed-off-by: Phil Elwell <phil@raspberrypi.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20230811155829.51208-1-phil@raspberrypi.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aadbf612f8b14984c7f7eacbdf05dab812b36f89
Author: Xingxing Luo <xingxing.luo@unisoc.com>
Date:   Fri Sep 22 15:59:29 2023 +0800

    usb: musb: Modify the "HWVers" register address
    
    commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream.
    
    musb HWVers rgister address is not 0x69, if we operate the
    wrong address 0x69, it will cause a kernel crash, because
    there is no register corresponding to this address in the
    additional control register of musb. In fact, HWVers has
    been defined in musb_register.h, and the name is
    "MUSB_HWVERS", so We need to use this macro instead of 0x69.
    
    Fixes: c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
    Link: https://lore.kernel.org/r/20230922075929.31074-1-xingxing.luo@unisoc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc929a0052c43a626112e1724e72691e4e54be56
Author: Xingxing Luo <xingxing.luo@unisoc.com>
Date:   Tue Sep 19 11:30:55 2023 +0800

    usb: musb: Get the musb_qh poniter after musb_giveback
    
    commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream.
    
    When multiple threads are performing USB transmission, musb->lock will be
    unlocked when musb_giveback is executed. At this time, qh may be released
    in the dequeue process in other threads, resulting in a wild pointer, so
    it needs to be here get qh again, and judge whether qh is NULL, and when
    dequeue, you need to set qh to NULL.
    
    Fixes: dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
    Link: https://lore.kernel.org/r/20230919033055.14085-1-xingxing.luo@unisoc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 459eb7c6885f9553848b7f8fc13a24da5435e812
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Sep 13 00:52:15 2023 +0000

    usb: dwc3: Soft reset phy on probe for host
    
    commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream.
    
    When there's phy initialization, we need to initiate a soft-reset
    sequence. That's done through USBCMD.HCRST in the xHCI driver and its
    initialization, However, the dwc3 driver may modify core configs before
    the soft-reset. This may result in some connection instability. So,
    ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR
    or other settings by issuing phy soft-reset.
    
    Note that some host-mode configurations may not expose device registers
    to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset
    through GUSB3PIPECTL and GUSB2PHYCFG instead.
    
    Cc: stable@vger.kernel.org
    Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
    Reported-by: Kenta Sato <tosainu.maple@gmail.com>
    Closes: https://lore.kernel.org/linux-usb/ZPUciRLUcjDywMVS@debian.me/
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Tested-by: Kenta Sato <tosainu.maple@gmail.com>
    Link: https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d71d0009f9e768dc87853626c6e89401ad6e1a41
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Tue Oct 10 00:26:14 2023 +0200

    net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read
    
    commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream.
    
    syzbot has found an uninit-value bug triggered by the dm9601 driver [1].
    
    This error happens because the variable res is not updated if the call
    to dm_read_shared_word returns an error. In this particular case -EPROTO
    was returned and res stayed uninitialized.
    
    This can be avoided by checking the return value of dm_read_shared_word
    and propagating the error if the read operation failed.
    
    [1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Reported-and-tested-by: syzbot+1f53a30781af65d2c955@syzkaller.appspotmail.com
    Acked-by: Peter Korsgaard <peter@korsgaard.com>
    Fixes: d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver")
    Link: https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bf69ee6bb416302a28427899fb13da70bd49eda
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Fri Sep 15 17:31:05 2023 +0300

    usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer
    
    commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream.
    
    As mentioned in:
      commit 474ed23a6257 ("xhci: align the last trb before link if it is
    easily splittable.")
    
    A bounce buffer is utilized for ensuring that transfers that span across
    ring segments are aligned to the EP's max packet size.  However, the device
    that is used to map the DMA buffer to is currently using the XHCI HCD,
    which does not carry any DMA operations in certain configrations.
    Migration to using the sysdev entry was introduced for DWC3 based
    implementations where the IOMMU operations are present.
    
    Replace the reference to the controller device to sysdev instead.  This
    allows the bounce buffer to be properly mapped to any implementations that
    have an IOMMU involved.
    
    cc: stable@vger.kernel.org
    Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20230915143108.1532163-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d30692c6c9442b1a8cd5405486d218836a385a6
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Wed Oct 4 18:35:28 2023 +0200

    dmaengine: stm32-mdma: abort resume if no ongoing transfer
    
    commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream.
    
    chan->desc can be null, if transfer is terminated when resume is called,
    leading to a NULL pointer when retrieving the hwdesc.
    To avoid this case, check that chan->desc is not null and channel is
    disabled (transfer previously paused or terminated).
    
    Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231004163531.2864160-1-amelie.delaunay@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d346a2ef6b1ebb77d740890cfaf8478c5b286380
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Fri Jul 7 17:24:14 2023 +0800

    media: mtk-jpeg: Fix use after free bug due to uncanceled work
    
    commit c677d7ae83141d390d1253abebafa49c962afb52 upstream.
    
    In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
    mtk_jpeg_job_timeout_work. Then mtk_jpeg_dec_device_run
    and mtk_jpeg_enc_device_run may be called to start the
    work.
    If we remove the module which will call mtk_jpeg_remove
    to make cleanup, there may be a unfinished work. The
    possible sequence is as follows, which will cause a
    typical UAF bug.
    
    Fix it by canceling the work before cleanup in the mtk_jpeg_remove
    
    CPU0                  CPU1
    
                        |mtk_jpeg_job_timeout_work
    mtk_jpeg_remove     |
      v4l2_m2m_release  |
        kfree(m2m_dev); |
                        |
                        | v4l2_m2m_get_curr_priv
                        |   m2m_dev->curr_ctx //use
    Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 014cab5329d18524749dacc25923938aab14ff57
Author: Patrick Rohr <prohr@google.com>
Date:   Fri Oct 13 14:44:14 2023 -0700

    net: release reference to inet6_dev pointer
    
    commit 5cb249686e67dbef3ffe53887fa725eefc5a7144 upstream.
    
    addrconf_prefix_rcv returned early without releasing the inet6_dev
    pointer when the PIO lifetime is less than accept_ra_min_lft.
    
    Fixes: 5027d54a9c30 ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
    Cc: Maciej Żenczykowski <maze@google.com>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Cc: David Ahern <dsahern@kernel.org>
    Cc: Simon Horman <horms@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: Patrick Rohr <prohr@google.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d491ac7aa12a09a1a48f9f6cbf628b29080ca9f4
Author: Patrick Rohr <prohr@google.com>
Date:   Fri Oct 13 14:44:13 2023 -0700

    net: change accept_ra_min_rtr_lft to affect all RA lifetimes
    
    commit 5027d54a9c30bc7ec808360378e2b4753f053f25 upstream.
    
    accept_ra_min_rtr_lft only considered the lifetime of the default route
    and discarded entire RAs accordingly.
    
    This change renames accept_ra_min_rtr_lft to accept_ra_min_lft, and
    applies the value to individual RA sections; in particular, router
    lifetime, PIO preferred lifetime, and RIO lifetime. If any of those
    lifetimes are lower than the configured value, the specific RA section
    is ignored.
    
    In order for the sysctl to be useful to Android, it should really apply
    to all lifetimes in the RA, since that is what determines the minimum
    frequency at which RAs must be processed by the kernel. Android uses
    hardware offloads to drop RAs for a fraction of the minimum of all
    lifetimes present in the RA (some networks have very frequent RAs (5s)
    with high lifetimes (2h)). Despite this, we have encountered networks
    that set the router lifetime to 30s which results in very frequent CPU
    wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the
    WiFi firmware) entirely on such networks, it seems better to ignore the
    misconfigured routers while still processing RAs from other IPv6 routers
    on the same network (i.e. to support IoT applications).
    
    The previous implementation dropped the entire RA based on router
    lifetime. This turned out to be hard to expand to the other lifetimes
    present in the RA in a consistent manner; dropping the entire RA based
    on RIO/PIO lifetimes would essentially require parsing the whole thing
    twice.
    
    Fixes: 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: Patrick Rohr <prohr@google.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20230726230701.919212-1-prohr@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 354a96770d94ce2cf2c9d4671b19401641877e9f
Author: Patrick Rohr <prohr@google.com>
Date:   Fri Oct 13 14:44:12 2023 -0700

    net: add sysctl accept_ra_min_rtr_lft
    
    commit 1671bcfd76fdc0b9e65153cf759153083755fe4c upstream.
    
    This change adds a new sysctl accept_ra_min_rtr_lft to specify the
    minimum acceptable router lifetime in an RA. If the received RA router
    lifetime is less than the configured value (and not 0), the RA is
    ignored.
    This is useful for mobile devices, whose battery life can be impacted
    by networks that configure RAs with a short lifetime. On such networks,
    the device should never gain IPv6 provisioning and should attempt to
    drop RAs via hardware offload, if available.
    
    Signed-off-by: Patrick Rohr <prohr@google.com>
    Cc: Maciej Żenczykowski <maze@google.com>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ceaf0d3a883bd5fa4433583ed8dfc2f2e8b9417
Author: Sasha Levin <sashal@kernel.org>
Date:   Sat Oct 14 12:40:41 2023 -0400

    Revert "spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe"
    
    This reverts commit 2cdec9c13f81313dd9f41f09c7cdecbfa4bea91d.
    
    Reported issues with the backport, revert for now.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 649237ccf440c1921a770435a708374faaa73ba5
Author: Sasha Levin <sashal@kernel.org>
Date:   Sat Oct 14 12:40:26 2023 -0400

    Revert "spi: zynqmp-gqspi: fix clock imbalance on probe failure"
    
    This reverts commit 19f3d5d13b756b913be582a9e0d0afdeca9c397e.
    
    Reported issues with backport, revert for now.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce03f0234f9da772272c4507c9c7bd39a5c87398
Author: Waiman Long <longman@redhat.com>
Date:   Tue Oct 10 22:48:42 2023 -0400

    workqueue: Override implicit ordered attribute in workqueue_apply_unbound_cpumask()
    
    [ Upstream commit ca10d851b9ad0338c19e8e3089e24d565ebfffd7 ]
    
    Commit 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1
    to be ordered") enabled implicit ordered attribute to be added to
    WQ_UNBOUND workqueues with max_active of 1. This prevented the changing
    of attributes to these workqueues leading to fix commit 0a94efb5acbb
    ("workqueue: implicit ordered attribute should be overridable").
    
    However, workqueue_apply_unbound_cpumask() was not updated at that time.
    So sysfs changes to wq_unbound_cpumask has no effect on WQ_UNBOUND
    workqueues with implicit ordered attribute. Since not all WQ_UNBOUND
    workqueues are visible on sysfs, we are not able to make all the
    necessary cpumask changes even if we iterates all the workqueue cpumasks
    in sysfs and changing them one by one.
    
    Fix this problem by applying the corresponding change made
    to apply_workqueue_attrs_locked() in the fix commit to
    workqueue_apply_unbound_cpumask().
    
    Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a424807d860ba816aaafc3064b46b456361c0802
Author: Jeremy Cline <jeremy@jcline.org>
Date:   Mon Oct 9 16:00:54 2023 -0400

    nfc: nci: assert requested protocol is valid
    
    [ Upstream commit 354a6e707e29cb0c007176ee5b8db8be7bd2dee0 ]
    
    The protocol is used in a bit mask to determine if the protocol is
    supported. Assert the provided protocol is less than the maximum
    defined so it doesn't potentially perform a shift-out-of-bounds and
    provide a clearer error for undefined protocols vs unsupported ones.
    
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Reported-and-tested-by: syzbot+0839b78e119aae1fec78@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0839b78e119aae1fec78
    Signed-off-by: Jeremy Cline <jeremy@jcline.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20231009200054.82557-1-jeremy@jcline.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5b03da30bd5bf260dcad83c5dece5fad70895f4
Author: Ralph Siemsen <ralph.siemsen@linaro.org>
Date:   Wed Oct 4 16:00:08 2023 -0400

    pinctrl: renesas: rzn1: Enable missing PINMUX
    
    [ Upstream commit f055ff23c331f28aa4ace4b72dc56f63b9a726c8 ]
    
    Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO
    pins will be configured as specified by the pinmux in the DTS.
    
    This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS,
    however that was removed, since the RZ/N1 driver does not call any of
    the generic pinmux functions.
    
    Fixes: 1308fb4e4eae14e6 ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}")
    Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20231004200008.1306798-1-ralph.siemsen@linaro.org
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Oct 9 12:31:10 2023 +0000

    net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
    
    [ Upstream commit 31c07dffafce914c1d1543c135382a11ff058d93 ]
    
    Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
    
    Getting a reference on the socket found in a lookup while
    holding a lock should happen before releasing the lock.
    
    nfc_llcp_sock_get_sn() has a similar problem.
    
    Finally nfc_llcp_recv_snl() needs to make sure the socket
    found by nfc_llcp_sock_from_sn() does not disappear.
    
    Fixes: 8f50020ed9b8 ("NFC: LLCP late binding")
    Reported-by: Sili Luo <rootlab@huawei.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20231009123110.3735515-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31ea13e3ff52e585ed792d984d2619560cd411ee
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Oct 6 15:53:09 2023 +0300

    ixgbe: fix crash with empty VF macvlan list
    
    [ Upstream commit 7b5add9af567c44e12196107f0fe106e194034fd ]
    
    The adapter->vf_mvs.l list needs to be initialized even if the list is
    empty.  Otherwise it will lead to crashes.
    
    Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Link: https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b24bd127750182529ce8cbe6b61dbe6e7e1c085d
Author: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
Date:   Thu Oct 5 21:06:35 2023 +0300

    net: phy: mscc: macsec: reject PN update requests
    
    [ Upstream commit e0a8c918daa58700609ebd45e3fcd49965be8bbc ]
    
    Updating the PN is not supported.
    Return -EINVAL if update_pn is true.
    
    The following command succeeded, but it should fail because the driver
    does not update the PN:
    ip macsec set macsec0 tx sa 0 pn 232 on
    
    Fixes: 28c5107aa904 ("net: phy: mscc: macsec support")
    Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a848ae8b5ad71e8ace04fbcc9faddb4cefc2b269
Author: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
Date:   Thu Oct 5 21:06:33 2023 +0300

    net: macsec: indicate next pn update when offloading
    
    [ Upstream commit 0412cc846a1ef38697c3f321f9b174da91ecd3b5 ]
    
    Indicate next PN update using update_pn flag in macsec_context.
    Offloaded MACsec implementations does not know whether or not the
    MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume
    that next PN should always updated, but this is not always true.
    
    The PN can be reset to its initial value using the following command:
    $ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case
    
    Or, the update PN command will succeed even if the driver does not support
    PN updates.
    $ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case
    
    Comparing the initial PN with the new PN value is not a solution. When
    the user updates the PN using its initial value the command will
    succeed, even if the driver does not support it. Like this:
    $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
    ead3664f508eb06c40ac7104cdae4ce5
    $ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case
    
    Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: e0a8c918daa5 ("net: phy: mscc: macsec: reject PN update requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a629f0575c9cbbd8dc98e2426391f8de27546a6a
Author: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date:   Tue Sep 5 18:02:03 2023 +0800

    drm/vmwgfx: fix typo of sizeof argument
    
    [ Upstream commit 39465cac283702a7d4a507a558db81898029c6d3 ]
    
    Since size of 'header' pointer and '*header' structure is equal on 64-bit
    machines issue probably didn't cause any wrong behavior. But anyway,
    fixing typo is required.
    
    Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.")
    Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
    Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Reviewed-by: Zack Rusin <zackr@vmware.com>
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230905100203.1716731-1-konstantin.meskhidze@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4ba78e5522ec975f875003b678d5833b6cc753d
Author: Björn Töpel <bjorn@rivosinc.com>
Date:   Wed Oct 4 14:07:05 2023 +0200

    riscv, bpf: Sign-extend return values
    
    [ Upstream commit 2f1b0d3d733169eb11680bfa97c266ae5e757148 ]
    
    The RISC-V architecture does not expose sub-registers, and hold all
    32-bit values in a sign-extended format [1] [2]:
    
      | The compiler and calling convention maintain an invariant that all
      | 32-bit values are held in a sign-extended format in 64-bit
      | registers. Even 32-bit unsigned integers extend bit 31 into bits
      | 63 through 32. Consequently, conversion between unsigned and
      | signed 32-bit integers is a no-op, as is conversion from a signed
      | 32-bit integer to a signed 64-bit integer.
    
    While BPF, on the other hand, exposes sub-registers, and use
    zero-extension (similar to arm64/x86).
    
    This has led to some subtle bugs, where a BPF JITted program has not
    sign-extended the a0 register (return value in RISC-V land), passed
    the return value up the kernel, e.g.:
    
      | int from_bpf(void);
      |
      | long foo(void)
      | {
      |    return from_bpf();
      | }
    
    Here, a0 would be 0xffff_ffff, instead of the expected
    0xffff_ffff_ffff_ffff.
    
    Internally, the RISC-V JIT uses a5 as a dedicated register for BPF
    return values.
    
    Keep a5 zero-extended, but explicitly sign-extend a0 (which is used
    outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs,
    a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL).
    
    Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G")
    Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2]
    Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2]
    Link: https://lore.kernel.org/bpf/20231004120706.52848-2-bjorn@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a8ef2234b3a0c129890556b2c4900870cb8411c
Author: Pu Lehui <pulehui@huawei.com>
Date:   Wed Feb 15 21:52:03 2023 +0800

    riscv, bpf: Factor out emit_call for kernel and bpf context
    
    [ Upstream commit 0fd1fd0104954380477353aea29c347e85dff16d ]
    
    The current emit_call function is not suitable for kernel function call as
    it store return value to bpf R0 register. We can separate it out for common
    use. Meanwhile, simplify judgment logic, that is, fixed function address
    can use jal or auipc+jalr, while the unfixed can use only auipc+jalr.
    
    Signed-off-by: Pu Lehui <pulehui@huawei.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Björn Töpel <bjorn@rivosinc.com>
    Acked-by: Björn Töpel <bjorn@rivosinc.com>
    Link: https://lore.kernel.org/bpf/20230215135205.1411105-3-pulehui@huaweicloud.com
    Stable-dep-of: 2f1b0d3d7331 ("riscv, bpf: Sign-extend return values")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bf4da1818c2e0c57d3171bb35260f4224368ff5
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Oct 5 16:08:31 2023 +0200

    xen-netback: use default TX queue size for vifs
    
    [ Upstream commit 66cf7435a26917c0c4d6245ad9137e7606e84fdf ]
    
    Do not set netback interfaces (vifs) default TX queue size to the ring size.
    The TX queue size is not related to the ring size, and using the ring size (32)
    as the queue size can lead to packet drops.  Note the TX side of the vif
    interface in the netback domain is the one receiving packets to be injected
    to the guest.
    
    Do not explicitly set the TX queue length to any value when creating the
    interface, and instead use the system default.  Note that the queue length can
    also be adjusted at runtime.
    
    Fixes: f942dc2552b8 ('xen network backend driver')
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Acked-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33548a6b3c7ce09adf53a9fe0556ceb1006c5c1e
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Oct 5 17:00:12 2023 +0300

    mlxsw: fix mlxsw_sp2_nve_vxlan_learning_set() return type
    
    [ Upstream commit 1e0b72a2a6432c0ef67ee5ce8d9172a7c20bba25 ]
    
    The mlxsw_sp2_nve_vxlan_learning_set() function is supposed to return
    zero on success or negative error codes.  So it needs to be type int
    instead of bool.
    
    Fixes: 4ee70efab68d ("mlxsw: spectrum_nve: Add support for VXLAN on Spectrum-2")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55e06850c7894f00d41b767c5f5665459f83f58f
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sat Oct 7 11:30:49 2023 +0800

    ieee802154: ca8210: Fix a potential UAF in ca8210_probe
    
    [ Upstream commit f990874b1c98fe8e57ee9385669f501822979258 ]
    
    If of_clk_add_provider() fails in ca8210_register_ext_clock(),
    it calls clk_unregister() to release priv->clk and returns an
    error. However, the caller ca8210_probe() then calls ca8210_remove(),
    where priv->clk is freed again in ca8210_unregister_ext_clock(). In
    this case, a use-after-free may happen in the second time we call
    clk_unregister().
    
    Fix this by removing the first clk_unregister(). Also, priv->clk could
    be an error code on failure of clk_register_fixed_rate(). Use
    IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
    
    Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Message-ID: <20231007033049.22353-1-dinghao.liu@zju.edu.cn>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef7a0d51bfdb987982001e5f72c9c3481c42d2d0
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Oct 5 10:12:00 2023 +0900

    ravb: Fix up dma_free_coherent() call in ravb_remove()
    
    [ Upstream commit e6864af61493113558c502b5cd0d754c19b93277 ]
    
    In ravb_remove(), dma_free_coherent() should be call after
    unregister_netdev(). Otherwise, this controller is possible to use
    the freed buffer.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20231005011201.14368-2-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1673841da013fd90f367140b4a0b9f1ff3badc87
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Thu Sep 7 18:26:16 2023 -0700

    drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow
    
    [ Upstream commit 95e681ca3b65e4ce3d2537b47672d787b7d30375 ]
    
    _dpu_plane_calc_bw() uses integer variables to calculate the bandwidth
    used during plane bandwidth calculations. However for high resolution
    displays this overflows easily and leads to below errors
    
    [dpu error]crtc83 failed performance check -7
    
    Promote the intermediate variables to u64 to avoid overflow.
    
    changes in v2:
            - change to u64 where actually needed in the math
    
    Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reported-by: Nia Espera <nespera@igalia.com>
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/32
    Tested-by: Nia Espera <nespera@igalia.com>
    Patchwork: https://patchwork.freedesktop.org/patch/556288/
    Link: https://lore.kernel.org/r/20230908012616.20654-1-quic_abhinavk@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6004ca7ad2d0301a492a691d1be1b71e104d4ec3
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Fri Sep 15 13:44:25 2023 -0700

    drm/msm/dsi: skip the wait for video mode done if not applicable
    
    [ Upstream commit ab483e3adcc178254eb1ce0fbdfbea65f86f1006 ]
    
    dsi_wait4video_done() API waits for the DSI video mode engine to
    become idle so that we can transmit the DCS commands in the
    beginning of BLLP. However, with the current sequence, the MDP
    timing engine is turned on after the panel's pre_enable() callback
    which can send out the DCS commands needed to power up the panel.
    
    During those cases, this API will always timeout and print out the
    error spam leading to long bootup times and log flooding.
    
    Fix this by checking if the DSI video engine was actually busy before
    waiting for it to become idle otherwise this is a redundant wait.
    
    changes in v2:
            - move the reg read below the video mode check
            - minor fixes in commit text
    
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/34
    Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/557853/
    Link: https://lore.kernel.org/r/20230915204426.19011-1-quic_abhinavk@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbbbeaef778686db4546f07699049be9060e1bfa
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Tue Aug 8 15:19:50 2023 -0700

    drm/msm/dp: do not reinitialize phy unless retry during link training
    
    [ Upstream commit 0c1a2e69bcb506f48ebf94bd199bab0b93f66da2 ]
    
    DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will
    cause PLL unlocked initially and then PLL gets locked at the end of
    initialization. PLL_UNLOCKED interrupt will fire during this time if the
    interrupt mask is enabled.
    
    However currently DP driver link training implementation incorrectly
    re-initializes PHY unconditionally during link training as the PHY was
    already configured in dp_ctrl_enable_mainlink_clocks().
    
    Fix this by re-initializing the PHY only if the previous link training
    failed.
    
    [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/30
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> # sc7280
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/551847/
    Link: https://lore.kernel.org/r/1691533190-19335-1-git-send-email-quic_khsieh@quicinc.com
    [quic_abhinavk@quicinc.com: added line break in commit text]
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31e7e77b24f1d4f1ae2c045bfec412af5858d8d6
Author: Jordan Rife <jrife@google.com>
Date:   Thu Sep 21 18:46:42 2023 -0500

    net: prevent address rewrite in kernel_bind()
    
    commit c889a99a21bf124c3db08d09df919f0eccc5ea4c upstream.
    
    Similar to the change in commit 0bdf399342c5("net: Avoid address
    overwrite in kernel_connect"), BPF hooks run on bind may rewrite the
    address passed to kernel_bind(). This change
    
    1) Makes a copy of the bind address in kernel_bind() to insulate
       callers.
    2) Replaces direct calls to sock->ops->bind() in net with kernel_bind()
    
    Link: https://lore.kernel.org/netdev/20230912013332.2048422-1-jrife@google.com/
    Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind")
    Cc: stable@vger.kernel.org
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Jordan Rife <jrife@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22c06bf1f99ec3ec16b1a81342becba4c59a1f16
Author: Jan Kara <jack@suse.cz>
Date:   Wed Oct 4 15:32:01 2023 +0200

    quota: Fix slow quotaoff
    
    commit 869b6ea1609f655a43251bf41757aa44e5350a8f upstream.
    
    Eric has reported that commit dabc8b207566 ("quota: fix dqput() to
    follow the guarantees dquot_srcu should provide") heavily increases
    runtime of generic/270 xfstest for ext4 in nojournal mode. The reason
    for this is that ext4 in nojournal mode leaves dquots dirty until the last
    dqput() and thus the cleanup done in quota_release_workfn() has to write
    them all. Due to the way quota_release_workfn() is written this results
    in synchronize_srcu() call for each dirty dquot which makes the dquot
    cleanup when turning quotas off extremely slow.
    
    To be able to avoid synchronize_srcu() for each dirty dquot we need to
    rework how we track dquots to be cleaned up. Instead of keeping the last
    dquot reference while it is on releasing_dquots list, we drop it right
    away and mark the dquot with new DQ_RELEASING_B bit instead. This way we
    can we can remove dquot from releasing_dquots list when new reference to
    it is acquired and thus there's no need to call synchronize_srcu() each
    time we drop dq_list_lock.
    
    References: https://lore.kernel.org/all/ZRytn6CxFK2oECUt@debian-BULLSEYE-live-builder-AMD64
    Reported-by: Eric Whitney <enwlinux@gmail.com>
    Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 093af62c023537f097d2ebdfaa0bc7c1a6e874e1
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 5 20:26:38 2023 +0200

    HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
    
    commit dac501397b9d81e4782232c39f94f4307b137452 upstream.
    
    hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
    races when it races with itself.
    
    hidpp_connect_event() primarily runs from a workqueue but it also runs
    on probe() and if a "device-connected" packet is received by the hw
    when the thread running hidpp_connect_event() from probe() is waiting on
    the hw, then a second thread running hidpp_connect_event() will be
    started from the workqueue.
    
    This opens the following races (note the below code is simplified):
    
    1. Retrieving + printing the protocol (harmless race):
    
            if (!hidpp->protocol_major) {
                    hidpp_root_get_protocol_version()
                    hidpp->protocol_major = response.rap.params[0];
            }
    
    We can actually see this race hit in the dmesg in the abrt output
    attached to rhbz#2227968:
    
    [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
    [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
    
    Testing with extra logging added has shown that after this the 2 threads
    take turn grabbing the hw access mutex (send_mutex) so they ping-pong
    through all the other TOCTOU cases managing to hit all of them:
    
    2. Updating the name to the HIDPP name (harmless race):
    
            if (hidpp->name == hdev->name) {
                    ...
                    hidpp->name = new_name;
            }
    
    3. Initializing the power_supply class for the battery (problematic!):
    
    hidpp_initialize_battery()
    {
            if (hidpp->battery.ps)
                    return 0;
    
            probe_battery(); /* Blocks, threads take turns executing this */
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    }
    
    4. Creating delayed input_device (potentially problematic):
    
            if (hidpp->delayed_input)
                    return;
    
            hidpp->delayed_input = hidpp_allocate_input(hdev);
    
    The really big problem here is 3. Hitting the race leads to the following
    sequence:
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    
            ...
    
            hidpp->battery.desc.properties =
                    devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
    
            hidpp->battery.ps =
                    devm_power_supply_register(&hidpp->hid_dev->dev,
                                               &hidpp->battery.desc, cfg);
    
    So now we have registered 2 power supplies for the same battery,
    which looks a bit weird from userspace's pov but this is not even
    the really big problem.
    
    Notice how:
    
    1. This is all devm-maganaged
    2. The hidpp->battery.desc struct is shared between the 2 power supplies
    3. hidpp->battery.desc.properties points to the result from the second
       devm_kmemdup()
    
    This causes a use after free scenario on USB disconnect of the receiver:
    1. The last registered power supply class device gets unregistered
    2. The memory from the last devm_kmemdup() call gets freed,
       hidpp->battery.desc.properties now points to freed memory
    3. The first registered power supply class device gets unregistered,
       this involves sending a remove uevent to userspace which invokes
       power_supply_uevent() to fill the uevent data
    4. power_supply_uevent() uses hidpp->battery.desc.properties which
       now points to freed memory leading to backtraces like this one:
    
    Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
    ...
    Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
    Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
    ...
    Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
    Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
    Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
    Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
    Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
    Sep 22 20:01:35 eric kernel:  power_supply_unregister+0x8e/0xa0
    Sep 22 20:01:35 eric kernel:  release_nodes+0x3d/0xb0
    Sep 22 20:01:35 eric kernel:  devres_release_group+0xfc/0x130
    Sep 22 20:01:35 eric kernel:  hid_device_remove+0x56/0xa0
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
    Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
    Sep 22 20:01:35 eric kernel:  logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4]
    Sep 22 20:01:35 eric kernel:  hid_device_remove+0x44/0xa0
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
    Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
    Sep 22 20:01:35 eric kernel:  usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3]
    Sep 22 20:01:35 eric kernel:  usb_unbind_interface+0x90/0x270
    Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
    Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
    Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
    Sep 22 20:01:35 eric kernel:  ? kobject_put+0xa0/0x1d0
    Sep 22 20:01:35 eric kernel:  usb_disable_device+0xcd/0x1e0
    Sep 22 20:01:35 eric kernel:  usb_disconnect+0xde/0x2c0
    Sep 22 20:01:35 eric kernel:  usb_disconnect+0xc3/0x2c0
    Sep 22 20:01:35 eric kernel:  hub_event+0xe80/0x1c10
    
    There have been quite a few bug reports (see Link tags) about this crash.
    
    Fix all the TOCTOU issues, including the really bad power-supply related
    system crash on USB disconnect, by making probe() use the workqueue for
    running hidpp_connect_event() too, so that it can never run more then once.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com
    Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb4a8146e3a9bff52d987941135f7703fda9d0e9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 12 10:17:39 2023 +0200

    lib/test_meminit: fix off-by-one error in test_pages()
    
    commit efb78fa86e95 ("lib/test_meminit: allocate pages up to order
    MAX_ORDER") works great in kernels 6.4 and newer thanks to commit
    23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely"), but for older
    kernels, the loop is off by one, which causes crashes when the test
    runs.
    
    Fix this up by changing "<= MAX_ORDER" "< MAX_ORDER" to allow the test
    to work properly for older kernel branches.
    
    Fixes: 2a1cf9fe09d9 ("lib/test_meminit: allocate pages up to order MAX_ORDER")
    Cc: Andrew Donnellan <ajd@linux.ibm.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Xiaoke Wang <xkernel.wang@foxmail.com>
    Cc: <stable@vger.kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06068e7f3ff8c0beddd30b978743d271479ecbb5
Author: Jing Zhang <renyu.zj@linux.alibaba.com>
Date:   Mon Sep 25 11:22:32 2023 +0800

    perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7
    
    [ Upstream commit 7f949f6f54ff593123ab95b6247bfa4542a65580 ]
    
    The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7
    to 0. But in arm_cmn_handle_irq(), only handled the overflow status of
    Bits[3:0] which results in unhandled overflow status of counters 4 to 7.
    
    So let the overflow status of DTC counters 4 to 7 to be handled.
    
    Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
    Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/1695612152-123633-1-git-send-email-renyu.zj@linux.alibaba.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ed2ad00f33392185cb54ea5cedf8fe0edaf3c0d
Author: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Date:   Tue Sep 5 15:40:48 2023 +0300

    RDMA/cxgb4: Check skb value for failure to allocate
    
    [ Upstream commit 8fb8a82086f5bda6893ea6557c5a458e4549c6d7 ]
    
    get_skb() can fail to allocate skb, so check it.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 5be78ee924ae ("RDMA/cxgb4: Fix LE hash collision bug for active open connection")
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Link: https://lore.kernel.org/r/20230905124048.284165-1-artem.chernyshev@red-soft.ru
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26788a5b48d9d5cd3283d777d238631c8cd7495a
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Wed Aug 23 13:57:27 2023 -0700

    RDMA/srp: Do not call scsi_done() from srp_abort()
    
    [ Upstream commit e193b7955dfad68035b983a0011f4ef3590c85eb ]
    
    After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
    callback, it performs one of the following actions:
    * Call scsi_queue_insert().
    * Call scsi_finish_command().
    * Call scsi_eh_scmd_add().
    Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
    the above actions would trigger a use-after-free. Hence remove the
    scsi_done() call from srp_abort(). Keep the srp_free_req() call
    before returning SUCCESS because we may not see the command again if
    SUCCESS is returned.
    
    Cc: Bob Pearson <rpearsonhpe@gmail.com>
    Cc: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81982125c352f2db1012c2cd37487e6c0c3b7da8
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Sun May 23 21:12:11 2021 -0700

    RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent
    
    [ Upstream commit ad215aaea4f9d637f441566cdbbc610e9849e1fa ]
    
    Define .init_cmd_priv and .exit_cmd_priv callback functions in struct
    scsi_host_template. Set .cmd_size such that the SCSI core allocates
    per-command private data. Use scsi_cmd_priv() to access that private
    data. Remove the req_ring pointer from struct srp_rdma_ch since it is no
    longer necessary. Convert srp_alloc_req_data() and srp_free_req_data()
    into functions that initialize one instance of the SRP-private command
    data. This is a micro-optimization since this patch removes several
    pointer dereferences from the hot path.
    
    Note: due to commit e73a5e8e8003 ("scsi: core: Only return started
    requests from scsi_host_find_tag()"), it is no longer necessary to protect
    the completion path against duplicate responses.
    
    Link: https://lore.kernel.org/r/20210524041211.9480-6-bvanassche@acm.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Stable-dep-of: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>