Linux 5.10.209

 
ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error [+ + +]
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue Dec 12 13:22:39 2023 -0800

    ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error
    
    [ Upstream commit 38c872a9e96f72f2947affc0526cc05659367d3d ]
    
    When both CONFIG_RAS_CEC and CONFIG_ACPI_EXTLOG are enabled, Linux does
    not clear the status word of the BIOS supplied error record for corrected
    errors. This may prevent logging of subsequent uncorrected errors.
    
    Fix by clearing the status.
    
    Fixes: 23ba710a0864 ("x86/mce: Fix all mce notifiers to update the mce->kflags bitmask")
    Reported-by: Erwin Tsaur <erwin.tsaur@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: LPIT: Avoid u32 multiplication overflow [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Thu Nov 9 21:08:59 2023 +0300

    ACPI: LPIT: Avoid u32 multiplication overflow
    
    [ Upstream commit 56d2eeda87995245300836ee4dbd13b002311782 ]
    
    In lpit_update_residency() there is a possibility of overflow
    in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
    
    Change multiplication to mul_u32_u32().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
acpi: property: Let args be NULL in __acpi_node_get_property_reference [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Nov 9 12:10:08 2023 +0200

    acpi: property: Let args be NULL in __acpi_node_get_property_reference
    
    [ Upstream commit bef52aa0f3de1b7d8c258c13b16e577361dabf3a ]
    
    fwnode_get_property_reference_args() may not be called with args argument
    NULL on ACPI, OF already supports this. Add the missing NULL checks and
    document this.
    
    The purpose is to be able to count the references.
    
    Fixes: 977d5ad39f3e ("ACPI: Convert ACPI reference args to generic fwnode reference args")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20231109101010.1329587-2-sakari.ailus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: resource: Add another DMI match for the TongFang GMxXGxx [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 23 15:57:06 2023 +0100

    ACPI: resource: Add another DMI match for the TongFang GMxXGxx
    
    commit df0cced74159c79e36ce7971f0bf250673296d93 upstream.
    
    The TongFang GMxXGxx, which needs IRQ overriding for the keyboard to work,
    is also sold as the Eluktronics RP-15 which does not use the standard
    TongFang GMxXGxx DMI board_name.
    
    Add an entry for this laptop to the irq1_edge_low_force_override[] DMI
    table to make the internal keyboard functional.
    
    Reported-by: Luis Acuna <ldacuna@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI: video: check for error while searching for backlight device parent [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Thu Nov 9 16:49:25 2023 +0300

    ACPI: video: check for error while searching for backlight device parent
    
    [ Upstream commit ccd45faf4973746c4f30ea41eec864e5cf191099 ]
    
    If acpi_get_parent() called in acpi_video_dev_register_backlight()
    fails, for example, because acpi_ut_acquire_mutex() fails inside
    acpi_get_parent), this can lead to incorrect (uninitialized)
    acpi_parent handle being passed to acpi_get_pci_dev() for detecting
    the parent pci device.
    
    Check acpi_get_parent() result and set parent device only in case of success.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9661e92c10a9 ("acpi: tie ACPI backlight devices to PCI devices if possible")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda - Fix speaker and headset mic pin config for CHUWI CoreBook XPro [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Fri Nov 17 20:09:23 2023 +0300

    ALSA: hda - Fix speaker and headset mic pin config for CHUWI CoreBook XPro
    
    [ Upstream commit 7c9caa299335df94ad1c58f70a22f16a540eab60 ]
    
    This patch corrected the speaker and headset mic pin config to the more
    appropriate values.
    
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20231117170923.106822-1-kovalev@altlinux.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/relatek: Enable Mute LED on HP Laptop 15s-fq2xxx [+ + +]
Author: Çağhan Demir <caghandemir@marun.edu.tr>
Date:   Mon Jan 15 20:23:03 2024 +0300

    ALSA: hda/relatek: Enable Mute LED on HP Laptop 15s-fq2xxx
    
    commit bc7863d18677df66b2c7a0e172c91296ff380f11 upstream.
    
    This HP Laptop uses ALC236 codec with COEF 0x07 idx 1 controlling
    the mute LED. This patch enables the already existing quirk for
    this device.
    
    Signed-off-by: Çağhan Demir <caghandemir@marun.edu.tr>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240115172303.4718-1-caghandemir@marun.edu.tr
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: oxygen: Fix right channel of capture volume mixer [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jan 12 12:10:23 2024 +0100

    ALSA: oxygen: Fix right channel of capture volume mixer
    
    commit a03cfad512ac24a35184d7d87ec0d5489e1cb763 upstream.
    
    There was a typo in oxygen mixer code that didn't update the right
    channel value properly for the capture volume.  Let's fix it.
    
    This trivial fix was originally reported on Bugzilla.
    
    Fixes: a3601560496d ("[ALSA] oxygen: add front panel controls")
    Cc: <stable@vger.kernel.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=156561
    Link: https://lore.kernel.org/r/20240112111023.6208-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
apparmor: avoid crash when parsed profile name is empty [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Thu Dec 28 19:07:43 2023 +0300

    apparmor: avoid crash when parsed profile name is empty
    
    [ Upstream commit 55a8210c9e7d21ff2644809699765796d4bfb200 ]
    
    When processing a packed profile in unpack_profile() described like
    
     "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
    
    a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
    passed to aa_splitn_fqname().
    
    aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
    Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
    aa_alloc_profile() crashes as the new profile name is NULL now.
    
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
    RIP: 0010:strlen+0x1e/0xa0
    Call Trace:
     <TASK>
     ? strlen+0x1e/0xa0
     aa_policy_init+0x1bb/0x230
     aa_alloc_profile+0xb1/0x480
     unpack_profile+0x3bc/0x4960
     aa_unpack+0x309/0x15e0
     aa_replace_profiles+0x213/0x33c0
     policy_update+0x261/0x370
     profile_replace+0x20e/0x2a0
     vfs_write+0x2af/0xe00
     ksys_write+0x126/0x250
     do_syscall_64+0x46/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
     </TASK>
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:strlen+0x1e/0xa0
    
    It seems such behaviour of aa_splitn_fqname() is expected and checked in
    other places where it is called (e.g. aa_remove_profiles). Well, there
    is an explicit comment "a ns name without a following profile is allowed"
    inside.
    
    AFAICS, nothing can prevent unpacked "name" to be in form like
    ":samba-dcerpcd" - it is passed from userspace.
    
    Deny the whole profile set replacement in such case and inform user with
    EPROTO and an explaining message.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 04dc715e24d0 ("apparmor: audit policy ns specified in policy load")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARC: fix spare error [+ + +]
Author: Vineet Gupta <vgupta@kernel.org>
Date:   Fri Dec 8 15:57:07 2023 -0800

    ARC: fix spare error
    
    [ Upstream commit aca02d933f63ba8bc84258bf35f9ffaf6b664336 ]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312082320.VDN5A9hb-lkp@intel.com/
    Signed-off-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: armada-3720-turris-mox: set irq type for RTC [+ + +]
Author: Sjoerd Simons <sjoerd@collabora.com>
Date:   Tue Nov 28 22:35:06 2023 +0100

    arm64: dts: armada-3720-turris-mox: set irq type for RTC
    
    commit fca8a117c1c9a0f8b8feed117db34cf58134dc2c upstream.
    
    The rtc on the mox shares its interrupt line with the moxtet bus. Set
    the interrupt type to be consistent between both devices. This ensures
    correct setup of the interrupt line regardless of probing order.
    
    Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
    Cc: <stable@vger.kernel.org> # v6.2+
    Fixes: 21aad8ba615e ("arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC")
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: qrb5165-rb5: correct LED panic indicator [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Nov 11 10:46:23 2023 +0100

    arm64: dts: qcom: qrb5165-rb5: correct LED panic indicator
    
    [ Upstream commit dc6b5562acbac0285ab3b2dad23930b6434bdfc6 ]
    
    There is no "panic-indicator" default trigger but a property with that
    name:
    
      qrb5165-rb5.dtb: leds: led-user4: Unevaluated properties are not allowed ('linux,default-trigger' was unexpected)
    
    Fixes: b5cbd84e499a ("arm64: dts: qcom: qrb5165-rb5: Add onboard LED support")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231111094623.12476-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845-db845c: correct LED panic indicator [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Nov 11 10:56:16 2023 +0100

    arm64: dts: qcom: sdm845-db845c: correct LED panic indicator
    
    [ Upstream commit 0c90c75e663246203a2b7f6dd9e08a110f4c3c43 ]
    
    There is no "panic-indicator" default trigger but a property with that
    name:
    
      sdm845-db845c.dtb: leds: led-0: Unevaluated properties are not allowed ('linux,default-trigger' was unexpected)
    
    Fixes: 3f72e2d3e682 ("arm64: dts: qcom: Add Dragonboard 845c")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231111095617.16496-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Mon Nov 6 11:57:48 2023 +0200

    arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type
    
    [ Upstream commit b57160859263c083c49482b0d083a586b1517f78 ]
    
    DSS irq trigger type is set to IRQ_TYPE_EDGE_RISING in the DT file, but
    the TRM says it is level triggered.
    
    For some reason triggering on rising edge results in double the amount
    of expected interrupts, e.g. for normal page flipping test the number of
    interrupts per second is 2 * fps. It is as if the IRQ triggers on both
    edges. There are no other side effects to this issue than slightly
    increased CPU & power consumption due to the extra interrupt.
    
    Switching to IRQ_TYPE_LEVEL_HIGH is correct and fixes the issue, so
    let's do that.
    
    Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Link: https://lore.kernel.org/r/20231106-am65-dss-clk-edge-v1-1-4a959fec0e1e@ideasonboard.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: davinci: always select CONFIG_CPU_ARM926T [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 8 12:00:36 2024 +0100

    ARM: davinci: always select CONFIG_CPU_ARM926T
    
    [ Upstream commit 40974ee421b4d1fc74ac733d86899ce1b83d8f65 ]
    
    The select was lost by accident during the multiplatform conversion.
    Any davinci-only
    
    arm-linux-gnueabi-ld: arch/arm/mach-davinci/sleep.o: in function `CACHE_FLUSH':
    (.text+0x168): undefined reference to `arm926_flush_kern_cache_all'
    
    Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5")
    Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/r/20240108110055.1531153-1-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: apq8064: correct XOADC register address [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Sep 28 14:02:35 2023 +0300

    ARM: dts: qcom: apq8064: correct XOADC register address
    
    [ Upstream commit 554557542e709e190eff8a598f0cde02647d533a ]
    
    The XOADC is present at the address 0x197 rather than just 197. It
    doesn't change a lot (since the driver hardcodes all register
    addresses), but the DT should present correct address anyway.
    
    Fixes: c4b70883ee33 ("ARM: dts: add XOADC and IIO HWMON to APQ8064")
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230928110309.1212221-3-dmitry.baryshkov@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: sun9i: smp: fix return code check of of_property_match_string [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Thu Dec 28 20:39:03 2023 +0100

    ARM: sun9i: smp: fix return code check of of_property_match_string
    
    [ Upstream commit 643fe70e7bcdcc9e2d96952f7fc2bab56385cce5 ]
    
    of_property_match_string returns an int; either an index from 0 or
    greater if successful or negative on failure. Even it's very
    unlikely that the DT CPU node contains multiple enable-methods
    these checks should be fixed.
    
    This patch was inspired by the work of Nick Desaulniers.
    
    Link: https://lore.kernel.org/lkml/20230516-sunxi-v1-1-ac4b9651a8c1@google.com/T/
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20231228193903.9078-2-wahrenst@gmx.net
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: cs35l33: Fix GPIO name and drop legacy include [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Dec 1 14:20:31 2023 +0100

    ASoC: cs35l33: Fix GPIO name and drop legacy include
    
    [ Upstream commit 50678d339d670a92658e5538ebee30447c88ccb3 ]
    
    This driver includes the legacy GPIO APIs <linux/gpio.h> and
    <linux/of_gpio.h> but does not use any symbols from any of
    them.
    
    Drop the includes.
    
    Further the driver is requesting "reset-gpios" rather than
    just "reset" from the GPIO framework. This is wrong because
    the gpiolib core will add "-gpios" before processing the
    request from e.g. device tree. Drop the suffix.
    
    The last problem means that the optional RESET GPIO has
    never been properly retrieved and used even if it existed,
    but nobody noticed.
    
    Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.")
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20231201-descriptors-sound-cirrus-v2-2-ee9f9d4655eb@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l34: Fix GPIO name and drop legacy include [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Dec 1 14:20:32 2023 +0100

    ASoC: cs35l34: Fix GPIO name and drop legacy include
    
    [ Upstream commit a6122b0b4211d132934ef99e7b737910e6d54d2f ]
    
    This driver includes the legacy GPIO APIs <linux/gpio.h> and
    <linux/of_gpio.h> but does not use any symbols from any of
    them.
    
    Drop the includes.
    
    Further the driver is requesting "reset-gpios" rather than
    just "reset" from the GPIO framework. This is wrong because
    the gpiolib core will add "-gpios" before processing the
    request from e.g. device tree. Drop the suffix.
    
    The last problem means that the optional RESET GPIO has
    never been properly retrieved and used even if it existed,
    but nobody noticed.
    
    Fixes: c1124c09e103 ("ASoC: cs35l34: Initial commit of the cs35l34 CODEC driver.")
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20231201-descriptors-sound-cirrus-v2-3-ee9f9d4655eb@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs43130: Fix incorrect frame delay configuration [+ + +]
Author: Maciej Strozek <mstrozek@opensource.cirrus.com>
Date:   Fri Nov 17 14:13:39 2023 +0000

    ASoC: cs43130: Fix incorrect frame delay configuration
    
    [ Upstream commit aa7e8e5e4011571022dc06e4d7a2f108feb53d1a ]
    
    Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231117141344.64320-3-mstrozek@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs43130: Fix the position of const qualifier [+ + +]
Author: Maciej Strozek <mstrozek@opensource.cirrus.com>
Date:   Fri Nov 17 14:13:38 2023 +0000

    ASoC: cs43130: Fix the position of const qualifier
    
    [ Upstream commit e7f289a59e76a5890a57bc27b198f69f175f75d9 ]
    
    Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231117141344.64320-2-mstrozek@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: da7219: Support low DC impedance headset [+ + +]
Author: David Rau <David.Rau.opensource@dm.renesas.com>
Date:   Fri Dec 1 12:29:33 2023 +0800

    ASoC: da7219: Support low DC impedance headset
    
    [ Upstream commit 5f44de697383fcc9a9a1a78f99e09d1838704b90 ]
    
    Change the default MIC detection impedance threshold to 200ohm
    to support low mic DC impedance headset.
    
    Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com>
    Link: https://lore.kernel.org/r/20231201042933.26392-1-David.Rau.opensource@dm.renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: Fix mem leak in few functions [+ + +]
Author: Kamil Duljas <kamil.duljas@gmail.com>
Date:   Thu Nov 16 13:51:50 2023 +0100

    ASoC: Intel: Skylake: Fix mem leak in few functions
    
    [ Upstream commit d5c65be34df73fa01ed05611aafb73b440d89e29 ]
    
    The resources should be freed when function return error.
    
    Signed-off-by: Kamil Duljas <kamil.duljas@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231116125150.1436-1-kamil.duljas@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: mem leak in skl register function [+ + +]
Author: Kamil Duljas <kamil.duljas@gmail.com>
Date:   Thu Nov 16 23:41:13 2023 +0100

    ASoC: Intel: Skylake: mem leak in skl register function
    
    [ Upstream commit f8ba14b780273fd290ddf7ee0d7d7decb44cc365 ]
    
    skl_platform_register() uses krealloc. When krealloc is fail,
    then previous memory is not freed. The leak is also when soc
    component registration failed.
    
    Signed-off-by: Kamil Duljas <kamil.duljas@gmail.com>
    Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231116224112.2209-2-kamil.duljas@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16 [+ + +]
Author: David Lin <CTLIN0@nuvoton.com>
Date:   Fri Nov 17 12:30:12 2023 +0800

    ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16
    
    [ Upstream commit c1501f2597dd08601acd42256a4b0a0fc36bf302 ]
    
    This issue is reproduced when W=1 build in compiler gcc-12.
    The following are sparse warnings:
    
    sound/soc/codecs/nau8822.c:199:25: sparse: sparse: incorrect type in assignment
    sound/soc/codecs/nau8822.c:199:25: sparse: expected unsigned short
    sound/soc/codecs/nau8822.c:199:25: sparse: got restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    sound/soc/codecs/nau8822.c:235:25: sparse: sparse: cast to restricted __be16
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202311122320.T1opZVkP-lkp@intel.com/
    Signed-off-by: David Lin <CTLIN0@nuvoton.com>
    Link: https://lore.kernel.org/r/20231117043011.1747594-1-CTLIN0@nuvoton.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5650: add mutex to avoid the jack detection failure [+ + +]
Author: Shuming Fan <shumingf@realtek.com>
Date:   Wed Nov 22 18:01:23 2023 +0800

    ASoC: rt5650: add mutex to avoid the jack detection failure
    
    [ Upstream commit cdba4301adda7c60a2064bf808e48fccd352aaa9 ]
    
    This patch adds the jd_mutex to protect the jack detection control flow.
    And only the headset type could check the button status.
    
    Signed-off-by: Shuming Fan <shumingf@realtek.com>
    Link: https://lore.kernel.org/r/20231122100123.2831753-1-shumingf@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8974: Correct boost mixer inputs [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Mon Nov 13 15:59:16 2023 +0000

    ASoC: wm8974: Correct boost mixer inputs
    
    [ Upstream commit 37e6fd0cebf0b9f71afb38fd95b10408799d1f0b ]
    
    Bit 6 of INPPGA (INPPGAMUTE) does not control the Aux path, it controls
    the input PGA path, as can been seen from Figure 8 Input Boost Stage in
    the datasheet. Update the naming of things in the driver to match this
    and update the routing to also reflect this.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231113155916.1741027-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: fix async space check for 0-sized buffers [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:33 2023 +0000

    binder: fix async space check for 0-sized buffers
    
    commit 3091c21d3e9322428691ce0b7a0cfa9c0b239eeb upstream.
    
    Move the padding of 0-sized buffers to an earlier stage to account for
    this round up during the alloc->free_async_space check.
    
    Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-5-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix comment on binder_alloc_new_buf() return value [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:36 2023 +0000

    binder: fix comment on binder_alloc_new_buf() return value
    
    commit e1090371e02b601cbfcea175c2a6cc7c955fa830 upstream.
    
    Update the comments of binder_alloc_new_buf() to reflect that the return
    value of the function is now ERR_PTR(-errno) on failure.
    
    No functional changes in this patch.
    
    Cc: stable@vger.kernel.org
    Fixes: 57ada2fb2250 ("binder: add log information for binder transaction failures")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-8-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix race between mmput() and do_exit() [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:32 2023 +0000

    binder: fix race between mmput() and do_exit()
    
    commit 9a9ab0d963621d9d12199df9817e66982582d5a5 upstream.
    
    Task A calls binder_update_page_range() to allocate and insert pages on
    a remote address space from Task B. For this, Task A pins the remote mm
    via mmget_not_zero() first. This can race with Task B do_exit() and the
    final mmput() refcount decrement will come from Task A.
    
      Task A            | Task B
      ------------------+------------------
      mmget_not_zero()  |
                        |  do_exit()
                        |    exit_mm()
                        |      mmput()
      mmput()           |
        exit_mmap()     |
          remove_vma()  |
            fput()      |
    
    In this case, the work of ____fput() from Task B is queued up in Task A
    as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
    work gets executed. However, Task A instead sleep, waiting for a reply
    from Task B that never comes (it's dead).
    
    This means the binder_deferred_release() is blocked until an unrelated
    binder event forces Task A to go back to userspace. All the associated
    death notifications will also be delayed until then.
    
    In order to fix this use mmput_async() that will schedule the work in
    the corresponding mm->async_put_work WQ instead of Task A.
    
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-4-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix trivial typo of binder_free_buf_locked() [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:35 2023 +0000

    binder: fix trivial typo of binder_free_buf_locked()
    
    commit 122a3c1cb0ff304c2b8934584fcfea4edb2fe5e3 upstream.
    
    Fix minor misspelling of the function in the comment section.
    
    No functional changes in this patch.
    
    Cc: stable@vger.kernel.org
    Fixes: 0f966cba95c7 ("binder: add flag to clear buffer on txn complete")
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-7-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix unused alloc->free_async_space [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:34 2023 +0000

    binder: fix unused alloc->free_async_space
    
    commit c6d05e0762ab276102246d24affd1e116a46aa0c upstream.
    
    Each transaction is associated with a 'struct binder_buffer' that stores
    the metadata about its buffer area. Since commit 74310e06be4d ("android:
    binder: Move buffer out of area shared with user space") this struct is
    no longer embedded within the buffer itself but is instead allocated on
    the heap to prevent userspace access to this driver-exclusive info.
    
    Unfortunately, the space of this struct is still being accounted for in
    the total buffer size calculation, specifically for async transactions.
    This results in an additional 104 bytes added to every async buffer
    request, and this area is never used.
    
    This wasted space can be substantial. If we consider the maximum mmap
    buffer space of SZ_4M, the driver will reserve half of it for async
    transactions, or 0x200000. This area should, in theory, accommodate up
    to 262,144 buffers of the minimum 8-byte size. However, after adding
    the extra 'sizeof(struct binder_buffer)', the total number of buffers
    drops to only 18,724, which is a sad 7.14% of the actual capacity.
    
    This patch fixes the buffer size calculation to enable the utilization
    of the entire async buffer space. This is expected to reduce the number
    of -ENOSPC errors that are seen on the field.
    
    Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-6-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: fix use-after-free in shinker's callback [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:31 2023 +0000

    binder: fix use-after-free in shinker's callback
    
    commit 3f489c2067c5824528212b0fc18b28d51332d906 upstream.
    
    The mmap read lock is used during the shrinker's callback, which means
    that using alloc->vma pointer isn't safe as it can race with munmap().
    As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
    munmap") the mmap lock is downgraded after the vma has been isolated.
    
    I was able to reproduce this issue by manually adding some delays and
    triggering page reclaiming through the shrinker's debug sysfs. The
    following KASAN report confirms the UAF:
    
      ==================================================================
      BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
      Read of size 8 at addr ffff356ed50e50f0 by task bash/478
    
      CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       zap_page_range_single+0x470/0x4b8
       binder_alloc_free_page+0x608/0xadc
       __list_lru_walk_one+0x130/0x3b0
       list_lru_walk_node+0xc4/0x22c
       binder_shrink_scan+0x108/0x1dc
       shrinker_debugfs_scan_write+0x2b4/0x500
       full_proxy_write+0xd4/0x140
       vfs_write+0x1ac/0x758
       ksys_write+0xf0/0x1dc
       __arm64_sys_write+0x6c/0x9c
    
      Allocated by task 492:
       kmem_cache_alloc+0x130/0x368
       vm_area_alloc+0x2c/0x190
       mmap_region+0x258/0x18bc
       do_mmap+0x694/0xa60
       vm_mmap_pgoff+0x170/0x29c
       ksys_mmap_pgoff+0x290/0x3a0
       __arm64_sys_mmap+0xcc/0x144
    
      Freed by task 491:
       kmem_cache_free+0x17c/0x3c8
       vm_area_free_rcu_cb+0x74/0x98
       rcu_core+0xa38/0x26d4
       rcu_core_si+0x10/0x1c
       __do_softirq+0x2fc/0xd24
    
      Last potentially related work creation:
       __call_rcu_common.constprop.0+0x6c/0xba0
       call_rcu+0x10/0x1c
       vm_area_free+0x18/0x24
       remove_vma+0xe4/0x118
       do_vmi_align_munmap.isra.0+0x718/0xb5c
       do_vmi_munmap+0xdc/0x1fc
       __vm_munmap+0x10c/0x278
       __arm64_sys_munmap+0x58/0x7c
    
    Fix this issue by performing instead a vma_lookup() which will fail to
    find the vma that was isolated before the mmap lock downgrade. Note that
    this option has better performance than upgrading to a mmap write lock
    which would increase contention. Plus, mmap_write_trylock() has been
    recently removed anyway.
    
    Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
    Cc: stable@vger.kernel.org
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-3-cmllamas@google.com
    [cmllamas: use find_vma() instead of vma_lookup() as commit ce6d42f2e4a2
     is missing in v5.10. This only works because we check the vma against
     our cached alloc->vma pointer.]
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: use EPOLLERR from eventpoll.h [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Dec 1 17:21:30 2023 +0000

    binder: use EPOLLERR from eventpoll.h
    
    commit 6ac061db9c58ca5b9270b1b3940d2464fb3ff183 upstream.
    
    Use EPOLLERR instead of POLLERR to make sure it is cast to the correct
    __poll_t type. This fixes the following sparse issue:
    
      drivers/android/binder.c:5030:24: warning: incorrect type in return expression (different base types)
      drivers/android/binder.c:5030:24:    expected restricted __poll_t
      drivers/android/binder.c:5030:24:    got int
    
    Fixes: f88982679f54 ("binder: check for binder_thread allocation failure in binder_poll()")
    Cc: stable@vger.kernel.org
    Cc: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20231201172212.1813387-2-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
blocklayoutdriver: Fix reference leak of pnfs_device_node [+ + +]
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Tue Dec 5 10:05:01 2023 -0500

    blocklayoutdriver: Fix reference leak of pnfs_device_node
    
    [ Upstream commit 1530827b90025cdf80c9b0d07a166d045a0a7b81 ]
    
    The error path for blocklayout's device lookup is missing a reference drop
    for the case where a lookup finds the device, but the device is marked with
    NFS_DEVICEID_UNAVAILABLE.
    
    Fixes: b3dce6a2f060 ("pnfs/blocklayout: handle transient devices")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btmtkuart: fix recv_buf() return value [+ + +]
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
Date:   Mon Dec 11 17:40:19 2023 +0100

    Bluetooth: btmtkuart: fix recv_buf() return value
    
    [ Upstream commit 64057f051f20c2a2184b9db7f8037d928d68a4f4 ]
    
    Serdev recv_buf() callback is supposed to return the amount of bytes
    consumed, therefore an int in between 0 and count.
    
    Do not return negative number in case of issue, just print an error and
    return count. This fixes a WARN in ttyport_receive_buf().
    
    Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc@kernel.org/
    Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Fix atomicity violation in {min,max}_key_size_set [+ + +]
Author: Gui-Dong Han <2045gemini@gmail.com>
Date:   Fri Dec 22 23:12:41 2023 +0800

    Bluetooth: Fix atomicity violation in {min,max}_key_size_set
    
    commit da9065caa594d19b26e1a030fd0cc27bd365d685 upstream.
    
    In min_key_size_set():
        if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE)
            return -EINVAL;
        hci_dev_lock(hdev);
        hdev->le_min_key_size = val;
        hci_dev_unlock(hdev);
    
    In max_key_size_set():
        if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size)
            return -EINVAL;
        hci_dev_lock(hdev);
        hdev->le_max_key_size = val;
        hci_dev_unlock(hdev);
    
    The atomicity violation occurs due to concurrent execution of set_min and
    set_max funcs.Consider a scenario where setmin writes a new, valid 'min'
    value, and concurrently, setmax writes a value that is greater than the
    old 'min' but smaller than the new 'min'. In this case, setmax might check
    against the old 'min' value (before acquiring the lock) but write its
    value after the 'min' has been updated by setmin. This leads to a
    situation where the 'max' value ends up being smaller than the 'min'
    value, which is an inconsistency.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team, BassCheck[1]. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations. The above
    possible bug is reported when our tool analyzes the source code of
    Linux 5.17.
    
    To resolve this issue, it is suggested to encompass the validity checks
    within the locked sections in both set_min and set_max funcs. The
    modification ensures that the validation of 'val' against the
    current min/max values is atomic, thus maintaining the integrity of the
    settings. With this patch applied, our tool no longer reports the bug,
    with the kernel configuration allyesconfig for x86_64. Due to the lack of
    associated hardware, we cannot test the patch in runtime testing, and just
    verify it according to the code logic.
    
    [1] https://sites.google.com/view/basscheck/
    
    Fixes: 18f81241b74f ("Bluetooth: Move {min,max}_key_size debugfs ...")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: Fix bogus check for re-auth no supported with non-ssp [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Nov 30 14:58:03 2023 +0100

    Bluetooth: Fix bogus check for re-auth no supported with non-ssp
    
    [ Upstream commit d03376c185926098cb4d668d6458801eb785c0a5 ]
    
    This reverts 19f8def031bfa50c579149b200bfeeb919727b27
    "Bluetooth: Fix auth_complete_evt for legacy units" which seems to be
    working around a bug on a broken controller rather then any limitation
    imposed by the Bluetooth spec, in fact if there ws not possible to
    re-auth the command shall fail not succeed.
    
    Fixes: 19f8def031bf ("Bluetooth: Fix auth_complete_evt for legacy units")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, lpm: Fix check prefixlen before walking trie [+ + +]
Author: Florian Lehner <dev@der-flo.net>
Date:   Sun Nov 5 09:58:01 2023 +0100

    bpf, lpm: Fix check prefixlen before walking trie
    
    [ Upstream commit 9b75dbeb36fcd9fc7ed51d370310d0518a387769 ]
    
    When looking up an element in LPM trie, the condition 'matchlen ==
    trie->max_prefixlen' will never return true, if key->prefixlen is larger
    than trie->max_prefixlen. Consequently all elements in the LPM trie will
    be visited and no element is returned in the end.
    
    To resolve this, check key->prefixlen first before walking the LPM trie.
    
    Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation")
    Signed-off-by: Florian Lehner <dev@der-flo.net>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20231105085801.3742-1-dev@der-flo.net
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add crosstask check to __bpf_get_stack [+ + +]
Author: Jordan Rome <jordalgo@meta.com>
Date:   Wed Nov 8 03:23:34 2023 -0800

    bpf: Add crosstask check to __bpf_get_stack
    
    [ Upstream commit b8e3a87a627b575896e448021e5c2f8a3bc19931 ]
    
    Currently get_perf_callchain only supports user stack walking for
    the current task. Passing the correct *crosstask* param will return
    0 frames if the task passed to __bpf_get_stack isn't the current
    one instead of a single incorrect frame/address. This change
    passes the correct *crosstask* param but also does a preemptive
    check in __bpf_get_stack if the task is current and returns
    -EOPNOTSUPP if it is not.
    
    This issue was found using bpf_get_task_stack inside a BPF
    iterator ("iter/task"), which iterates over all tasks.
    bpf_get_task_stack works fine for fetching kernel stacks
    but because get_perf_callchain relies on the caller to know
    if the requested *task* is the current one (via *crosstask*)
    it was failing in a confusing way.
    
    It might be possible to get user stacks for all tasks utilizing
    something like access_process_vm but that requires the bpf
    program calling bpf_get_task_stack to be sleepable and would
    therefore be a breaking change.
    
    Fixes: fa28dcb82a38 ("bpf: Introduce helper bpf_get_task_stack()")
    Signed-off-by: Jordan Rome <jordalgo@meta.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20231108112334.3433136-1-jordalgo@meta.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: fix check for attempt to corrupt spilled pointer [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Tue Dec 5 10:42:41 2023 -0800

    bpf: fix check for attempt to corrupt spilled pointer
    
    [ Upstream commit ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae ]
    
    When register is spilled onto a stack as a 1/2/4-byte register, we set
    slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,
    depending on actual spill size). So to check if some stack slot has
    spilled register we need to consult slot_type[7], not slot_type[0].
    
    To avoid the need to remember and double-check this in the future, just
    use is_spilled_reg() helper.
    
    Fixes: 27113c59b6d0 ("bpf: Check the other end of slot_type for STACK_SPILL")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20231205184248.1502704-4-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix verification of indirect var-off stack access [+ + +]
Author: Andrei Matei <andreimatei1@gmail.com>
Date:   Wed Dec 6 23:11:48 2023 -0500

    bpf: Fix verification of indirect var-off stack access
    
    [ Upstream commit a833a17aeac73b33f79433d7cee68d5cafd71e4f ]
    
    This patch fixes a bug around the verification of possibly-zero-sized
    stack accesses. When the access was done through a var-offset stack
    pointer, check_stack_access_within_bounds was incorrectly computing the
    maximum-offset of a zero-sized read to be the same as the register's min
    offset. Instead, we have to take in account the register's maximum
    possible value. The patch also simplifies how the max offset is checked;
    the check is now simpler than for min offset.
    
    The bug was allowing accesses to erroneously pass the
    check_stack_access_within_bounds() checks, only to later crash in
    check_stack_range_initialized() when all the possibly-affected stack
    slots are iterated (this time with a correct max offset).
    check_stack_range_initialized() is relying on
    check_stack_access_within_bounds() for its accesses to the
    stack-tracking vector to be within bounds; in the case of zero-sized
    accesses, we were essentially only verifying that the lowest possible
    slot was within bounds. We would crash when the max-offset of the stack
    pointer was >= 0 (which shouldn't pass verification, and hopefully is
    not something anyone's code attempts to do in practice).
    
    Thanks Hao for reporting!
    
    Fixes: 01f810ace9ed3 ("bpf: Allow variable-offset stack access")
    Reported-by: Hao Sun <sunhao.th@gmail.com>
    Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Eduard Zingerman <eddyz87@gmail.com>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20231207041150.229139-2-andreimatei1@gmail.com
    
    Closes: https://lore.kernel.org/bpf/CACkBjsZGEUaRCHsmaX=h-efVogsRfK1FPxmkgb0Os_frnHiNdw@mail.gmail.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
calipso: fix memory leak in netlbl_calipso_add_pass() [+ + +]
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Thu Nov 23 09:25:54 2023 +0000

    calipso: fix memory leak in netlbl_calipso_add_pass()
    
    [ Upstream commit ec4e9d630a64df500641892f4e259e8149594a99 ]
    
    If IPv6 support is disabled at boot (ipv6.disable=1),
    the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
    and the netlbl_calipso_ops_get() function always returns NULL.
    In this case, the netlbl_calipso_add_pass() function allocates memory
    for the doi_def variable but doesn't free it with the calipso_doi_free().
    
    BUG: memory leak
    unreferenced object 0xffff888011d68180 (size 64):
      comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
      hex dump (first 32 bytes):
        00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<...>] kmalloc include/linux/slab.h:552 [inline]
        [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
        [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
        [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
        [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
        [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
        [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
        [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
        [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
        [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
        [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
        [<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
        [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
        [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
        [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
        [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
        [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
        [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with Syzkaller
    
    Fixes: cb72d38211ea ("netlabel: Initial support for the CALIPSO netlink protocol.")
    Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
    [PM: merged via the LSM tree at Jakub Kicinski request]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: fixed-rate: add devm_clk_hw_register_fixed_rate [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Sep 16 09:17:39 2022 +0300

    clk: fixed-rate: add devm_clk_hw_register_fixed_rate
    
    [ Upstream commit 1d7d20658534c7d36fe6f4252f6f1a27d9631a99 ]
    
    Add devm_clk_hw_register_fixed_rate(), devres-managed helper to register
    fixed-rate clock.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20220916061740.87167-3-dmitry.baryshkov@linaro.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: ee0cf5e07f44 ("clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw [+ + +]
Author: Théo Lebrun <theo.lebrun@bootlin.com>
Date:   Mon Dec 18 18:14:16 2023 +0100

    clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw
    
    [ Upstream commit ee0cf5e07f44a10fce8f1bfa9db226c0b5ecf880 ]
    
    Add missing comma and remove extraneous NULL argument. The macro is
    currently used by no one which explains why the typo slipped by.
    
    Fixes: 2d34f09e79c9 ("clk: fixed-rate: Add support for specifying parents via DT/pointers")
    Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
    Link: https://lore.kernel.org/r/20231218-mbly-clk-v1-1-44ce54108f06@bootlin.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Wed Nov 22 09:58:14 2023 +0530

    clk: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config
    
    [ Upstream commit 6ebd9a4f8b8d2b35cf965a04849c4ba763722f13 ]
    
    Update the test_ctl_hi_val and test_ctl_hi1_val of gpu_cc_pll1
    as per latest HW recommendation.
    
    Fixes: 0cef71f2ccc8 ("clk: qcom: Add graphics clock controller driver for SM8150")
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231122042814.4158076-1-quic_skakitap@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: videocc-sm8150: Add missing PLL config property [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Fri Dec 1 15:20:26 2023 +0530

    clk: qcom: videocc-sm8150: Add missing PLL config property
    
    [ Upstream commit 71f130c9193f613d497f7245365ed05ffdb0a401 ]
    
    When the driver was ported upstream, PLL test_ctl_hi1 register value
    was omitted. Add it to ensure the PLLs are fully configured.
    
    Fixes: 5658e8cf1a8a ("clk: qcom: add video clock controller driver for SM8150")
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231201-videocc-8150-v3-3-56bec3a5e443@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: videocc-sm8150: Update the videocc resets [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Fri Dec 1 15:20:25 2023 +0530

    clk: qcom: videocc-sm8150: Update the videocc resets
    
    [ Upstream commit 1fd9a939db24d2f66e48f8bca3e3654add3fa205 ]
    
    Add all the available resets for the video clock controller
    on sm8150.
    
    Fixes: 5658e8cf1a8a ("clk: qcom: add video clock controller driver for SM8150")
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231201-videocc-8150-v3-2-56bec3a5e443@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: rockchip: rk3128: Fix HCLK_OTG gate register [+ + +]
Author: Weihao Li <cn.liweihao@gmail.com>
Date:   Tue Oct 31 19:18:16 2023 +0800

    clk: rockchip: rk3128: Fix HCLK_OTG gate register
    
    [ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ]
    
    The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON.
    
    Signed-off-by: Weihao Li <cn.liweihao@gmail.com>
    Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: si5341: fix an error code problem in si5341_output_clk_set_rate [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Wed Nov 1 11:16:36 2023 +0800

    clk: si5341: fix an error code problem in si5341_output_clk_set_rate
    
    [ Upstream commit 5607068ae5ab02c3ac9cabc6859d36e98004c341 ]
    
    regmap_bulk_write() return zero or negative error code, return the value
    of regmap_bulk_write() rather than '0'.
    
    Fixes: 3044a860fd09 ("clk: Add Si5341/Si5340 driver")
    Acked-by: Mike Looijmans <mike.looijmans@topic.nl>
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Link: https://lore.kernel.org/r/20231101031633.996124-1-suhui@nfschina.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: zynqmp: Add a check for NULL pointer [+ + +]
Author: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Date:   Wed May 18 11:23:14 2022 +0530

    clk: zynqmp: Add a check for NULL pointer
    
    [ Upstream commit 6ab9810cfe6c8f3d8b8750c827d7870abd3751b9 ]
    
    Add a NULL pointer check as clk_hw_get_parent can return NULL.
    
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Link: https://lore.kernel.org/r/20220518055314.2486-1-shubhrajyoti.datta@xilinx.com
    Acked-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 1fe15be1fb61 ("drivers: clk: zynqmp: update divider round rate logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: zynqmp: make bestdiv unsigned [+ + +]
Author: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Date:   Thu Aug 18 17:01:53 2022 +0530

    clk: zynqmp: make bestdiv unsigned
    
    [ Upstream commit d3954b51b475c4848179cd90b24ac73684cdc76b ]
    
    Divisor is always positive make it u32 *.
    Also the arguments passed are currently of u32 pointers.
    
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
    Link: https://lore.kernel.org/r/20220818113153.14431-1-shubhrajyoti.datta@amd.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 1fe15be1fb61 ("drivers: clk: zynqmp: update divider round rate logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
coresight: etm4x: Fix width of CCITMIN field [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Nov 1 11:52:06 2023 +0000

    coresight: etm4x: Fix width of CCITMIN field
    
    commit cc0271a339cc70cae914c3ec20edc2a8058407da upstream.
    
    CCITMIN is a 12 bit field and doesn't fit in a u8, so extend it to u16.
    This probably wasn't an issue previously because values higher than 255
    never occurred.
    
    But since commit 4aff040bcc8d ("coresight: etm: Override TRCIDR3.CCITMIN
    on errata affected cpus"), a comparison with 256 was done to enable the
    errata, generating the following W=1 build error:
    
      coresight-etm4x-core.c:1188:24: error: result of comparison of
      constant 256 with expression of type 'u8' (aka 'unsigned char') is
      always false [-Werror,-Wtautological-constant-out-of-range-compare]
    
       if (drvdata->ccitmin == 256)
    
    Cc: stable@vger.kernel.org
    Fixes: 2e1cdfe184b5 ("coresight-etm4x: Adding CoreSight ETM4x driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310302043.as36UFED-lkp@intel.com/
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: James Clark <james.clark@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20231101115206.70810-1-james.clark@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider() [+ + +]
Author: Alexandra Diupina <adiupina@astralinux.ru>
Date:   Tue Dec 5 18:12:20 2023 +0300

    cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
    
    [ Upstream commit c4a5118a3ae1eadc687d84eef9431f9e13eb015c ]
    
    devm_of_clk_add_hw_provider() may return an errno, so
    add a return value check
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider")
    Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: Use of_property_present() for testing DT property presence [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Fri Mar 10 08:47:02 2023 -0600

    cpufreq: Use of_property_present() for testing DT property presence
    
    [ Upstream commit b8f3a396a7ee43e6079176cc0fb8de2b95a23681 ]
    
    It is preferred to use typed property access functions (i.e.
    of_property_read_<type> functions) rather than low-level
    of_get_property/of_find_property functions for reading properties. As
    part of this, convert of_get_property/of_find_property calls to the
    recently added of_property_present() helper when we just want to test
    for presence of a property and nothing more.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Stable-dep-of: c4a5118a3ae1 ("cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: af_alg - Disallow multiple in-flight AIO requests [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 28 16:25:49 2023 +0800

    crypto: af_alg - Disallow multiple in-flight AIO requests
    
    [ Upstream commit 67b164a871af1d736f131fd6fe78a610909f06f3 ]
    
    Having multiple in-flight AIO requests results in unpredictable
    output because they all share the same IV.  Fix this by only allowing
    one request at a time.
    
    Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to algif_aead")
    Fixes: a596999b7ddf ("crypto: algif - change algif_skcipher to be asynchronous")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccp - fix memleak in ccp_init_dm_workarea [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Nov 27 11:47:10 2023 +0800

    crypto: ccp - fix memleak in ccp_init_dm_workarea
    
    [ Upstream commit a1c95dd5bc1d6a5d7a75a376c2107421b7d6240d ]
    
    When dma_map_single() fails, wa->address is supposed to be freed
    by the callers of ccp_init_dm_workarea() through ccp_dm_free().
    However, many of the call spots don't expect to have to call
    ccp_dm_free() on failure of ccp_init_dm_workarea(), which may
    lead to a memleak. Let's free wa->address in ccp_init_dm_workarea()
    when dma_map_single() fails.
    
    Fixes: 63b945091a07 ("crypto: ccp - CCP device driver and interface support")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sa2ul - Return crypto_aead_setkey to transfer the error [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Mon Nov 27 02:03:01 2023 +0000

    crypto: sa2ul - Return crypto_aead_setkey to transfer the error
    
    [ Upstream commit ce852f1308ac738e61c5b2502517deea593a1554 ]
    
    Return crypto_aead_setkey() in order to transfer the error if
    it fails.
    
    Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - avoid skcipher fallback code duplication [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:25 2023 +0200

    crypto: sahara - avoid skcipher fallback code duplication
    
    [ Upstream commit 01d70a4bbff20ea05cadb4c208841985a7cc6596 ]
    
    Factor out duplicated skcipher fallback handling code to a helper function
    sahara_aes_fallback(). Also, keep a single check if fallback is required in
    sahara_aes_crypt().
    
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: d1d6351e37aa ("crypto: sahara - handle zero-length aes requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - do not resize req->src when doing hash operations [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:36 2023 +0200

    crypto: sahara - do not resize req->src when doing hash operations
    
    [ Upstream commit a3c6f4f4d249cecaf2f34471aadbfb4f4ef57298 ]
    
    When testing sahara sha256 speed performance with tcrypt (mode=404) on
    imx53-qsrb board, multiple "Invalid numbers of src SG." errors are
    reported. This was traced to sahara_walk_and_recalc() resizing req->src
    and causing the subsequent dma_map_sg() call to fail.
    
    Now that the previous commit fixed sahara_sha_hw_links_create() to take
    into account the actual request size, rather than relying on sg->length
    values, the resize operation is no longer necessary.
    
    Therefore, remove sahara_walk_and_recalc() and simplify associated logic.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix ahash reqsize [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:32 2023 +0200

    crypto: sahara - fix ahash reqsize
    
    [ Upstream commit efcb50f41740ac55e6ccc4986c1a7740e21c62b4 ]
    
    Set the reqsize for sha algorithms to sizeof(struct sahara_sha_reqctx), the
    extra space is not needed.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix ahash selftest failure [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:21 2023 +0200

    crypto: sahara - fix ahash selftest failure
    
    [ Upstream commit afffcf3db98b9495114b79d5381f8cc3f69476fb ]
    
    update() calls should not modify the result buffer, so add an additional
    check for "rctx->last" to make sure that only the final hash value is
    copied into the buffer.
    
    Fixes the following selftest failure:
    alg: ahash: sahara-sha256 update() used result buffer on test vector 3,
    cfg="init+update+final aligned buffer"
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix cbc selftest failure [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:20 2023 +0200

    crypto: sahara - fix cbc selftest failure
    
    [ Upstream commit 9f10bc28c0fb676ae58aa3bfa358db8f5de124bb ]
    
    The kernel crypto API requires that all CBC implementations update the IV
    buffer to contain the last ciphertext block.
    
    This fixes the following cbc selftest error:
    alg: skcipher: sahara-cbc-aes encryption test failed (wrong output IV) on
    test vector 0, cfg="in-place (one sglist)"
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix error handling in sahara_hw_descriptor_create() [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:23 2023 +0200

    crypto: sahara - fix error handling in sahara_hw_descriptor_create()
    
    [ Upstream commit ee6e6f0a7f5b39d50a5ef5fcc006f4f693db18a7 ]
    
    Do not call dma_unmap_sg() for scatterlists that were not mapped
    successfully.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix processing hash requests with req->nbytes < sg->length [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:35 2023 +0200

    crypto: sahara - fix processing hash requests with req->nbytes < sg->length
    
    [ Upstream commit 7bafa74d1ba35dcc173e1ce915e983d65905f77e ]
    
    It's not always the case that the entire sg entry needs to be processed.
    Currently, when nbytes is less than sg->length, "Descriptor length" errors
    are encountered.
    
    To fix this, take the actual request size into account when populating the
    hw links.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix processing requests with cryptlen < sg->length [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:22 2023 +0200

    crypto: sahara - fix processing requests with cryptlen < sg->length
    
    [ Upstream commit 5b8668ce3452827d27f8c34ff6ba080a8f983ed0 ]
    
    It's not always the case that the entire sg entry needs to be processed.
    Currently, when cryptlen is less than sg->legth, "Descriptor length" errors
    are encountered.
    
    The error was noticed when testing xts(sahara-ecb-aes) with arbitrary sized
    input data. To fix this, take the actual request size into account when
    populating the hw links.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - fix wait_for_completion_timeout() error handling [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:33 2023 +0200

    crypto: sahara - fix wait_for_completion_timeout() error handling
    
    [ Upstream commit 2dba8e1d1a7957dcbe7888846268538847b471d1 ]
    
    The sg lists are not unmapped in case of timeout errors. Fix this.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - handle zero-length aes requests [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:31 2023 +0200

    crypto: sahara - handle zero-length aes requests
    
    [ Upstream commit d1d6351e37aac14b32a291731d0855996c459d11 ]
    
    In case of a zero-length input, exit gracefully from sahara_aes_crypt().
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - improve error handling in sahara_sha_process() [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Sun Dec 24 10:21:34 2023 +0200

    crypto: sahara - improve error handling in sahara_sha_process()
    
    [ Upstream commit 5deff027fca49a1eb3b20359333cf2ae562a2343 ]
    
    sahara_sha_hw_data_descriptor_create() returns negative error codes on
    failure, so make sure the errors are correctly handled / propagated.
    
    Fixes: 5a2bb93f5992 ("crypto: sahara - add support for SHA1/256")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: sahara - remove FLAGS_NEW_KEY logic [+ + +]
Author: Ovidiu Panait <ovidiu.panait@windriver.com>
Date:   Fri Dec 1 19:06:19 2023 +0200

    crypto: sahara - remove FLAGS_NEW_KEY logic
    
    [ Upstream commit 8fd183435728b139248a77978ea3732039341779 ]
    
    Remove the FLAGS_NEW_KEY logic as it has the following issues:
    - the wrong key may end up being used when there are multiple data streams:
           t1            t2
        setkey()
        encrypt()
                       setkey()
                       encrypt()
    
        encrypt() <--- key from t2 is used
    - switching between encryption and decryption with the same key is not
      possible, as the hdr flags are only updated when a new setkey() is
      performed
    
    With this change, the key is always sent along with the cryptdata when
    performing encryption/decryption operations.
    
    Fixes: 5de8875281e1 ("crypto: sahara - Add driver for SAHARA2 accelerator.")
    Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: scomp - fix req->dst buffer overflow [+ + +]
Author: Chengming Zhou <zhouchengming@bytedance.com>
Date:   Wed Dec 27 09:35:23 2023 +0000

    crypto: scomp - fix req->dst buffer overflow
    
    [ Upstream commit 744e1885922a9943458954cfea917b31064b4131 ]
    
    The req->dst buffer size should be checked before copying from the
    scomp_scratch->dst to avoid req->dst buffer overflow problem.
    
    Fixes: 1ab53a77b772 ("crypto: acomp - add driver-side scomp interface")
    Reported-by: syzbot+3eff5e51bf1db122a16e@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/0000000000000b05cd060d6b5511@google.com/
    Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
    Reviewed-by: Barry Song <v-songbaohua@oppo.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: virtio - Handle dataq logic with tasklet [+ + +]
Author: Gonglei (Arei) <arei.gonglei@huawei.com>
Date:   Mon Nov 20 11:49:45 2023 +0000

    crypto: virtio - Handle dataq logic with tasklet
    
    [ Upstream commit fed93fb62e05c38152b0fc1dc9609639e63eed76 ]
    
    Doing ipsec produces a spinlock recursion warning.
    This is due to crypto_finalize_request() being called in the upper half.
    Move virtual data queue processing of virtio-crypto driver to tasklet.
    
    Fixes: dbaf0624ffa57 ("crypto: add virtio-crypto driver")
    Reported-by: Halil Pasic <pasic@linux.ibm.com>
    Signed-off-by: wangyangxin <wangyangxin1@huawei.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: virtio - Wait for tasklet to complete on device remove [+ + +]
Author: wangyangxin <wangyangxin1@huawei.com>
Date:   Mon Dec 11 19:42:15 2023 +0800

    crypto: virtio - Wait for tasklet to complete on device remove
    
    [ Upstream commit 67cc511e8d436456cc98033e6d4ba83ebfc8e672 ]
    
    The scheduled tasklet needs to be executed on device remove.
    
    Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: wangyangxin <wangyangxin1@huawei.com>
    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
debugfs: fix automount d_fsdata usage [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Nov 24 17:25:24 2023 +0100

    debugfs: fix automount d_fsdata usage
    
    [ Upstream commit 0ed04a1847a10297595ac24dc7d46b35fb35f90a ]
    
    debugfs_create_automount() stores a function pointer in d_fsdata,
    but since commit 7c8d469877b1 ("debugfs: add support for more
    elaborate ->d_fsdata") debugfs_release_dentry() will free it, now
    conditionally on DEBUGFS_FSDATA_IS_REAL_FOPS_BIT, but that's not
    set for the function pointer in automount. As a result, removing
    an automount dentry would attempt to free the function pointer.
    Luckily, the only user of this (tracing) never removes it.
    
    Nevertheless, it's safer if we just handle the fsdata in one way,
    namely either DEBUGFS_FSDATA_IS_REAL_FOPS_BIT or allocated. Thus,
    change the automount to allocate it, and use the real_fops in the
    data to indicate whether or not automount is filled, rather than
    adding a type tag. At least for now this isn't actually needed,
    but the next changes will require it.
    
    Also check in debugfs_file_get() that it gets only called
    on regular files, just to make things clearer.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-mapping: Add dma_release_coherent_memory to DMA API [+ + +]
Author: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Date:   Fri Apr 22 14:24:35 2022 +0800

    dma-mapping: Add dma_release_coherent_memory to DMA API
    
    [ Upstream commit e61c451476e61450f6771ce03bbc01210a09be16 ]
    
    Add dma_release_coherent_memory to DMA API to allow dma
    user call it to release dev->dma_mem when the device is
    removed.
    
    Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
    Acked-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220422062436.14384-2-mark-pk.tsai@mediatek.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Stable-dep-of: b07bc2347672 ("dma-mapping: clear dev->dma_mem to NULL after freeing it")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dma-mapping: clear dev->dma_mem to NULL after freeing it [+ + +]
Author: Joakim Zhang <joakim.zhang@cixtech.com>
Date:   Thu Dec 14 16:25:26 2023 +0800

    dma-mapping: clear dev->dma_mem to NULL after freeing it
    
    [ Upstream commit b07bc2347672cc8c7293c64499f1488278c5ca3d ]
    
    Reproduced with below sequence:
    dma_declare_coherent_memory()->dma_release_coherent_memory()
    ->dma_declare_coherent_memory()->"return -EBUSY" error
    
    It will return -EBUSY from the dma_assign_coherent_memory()
    in dma_declare_coherent_memory(), the reason is that dev->dma_mem
    pointer has not been set to NULL after it's freed.
    
    Fixes: cf65a0f6f6ff ("dma-mapping: move all DMA mapping code to kernel/dma")
    Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dma-mapping: Fix build error unused-value [+ + +]
Author: Ren Zhijie <renzhijie2@huawei.com>
Date:   Thu Jun 30 20:35:28 2022 +0800

    dma-mapping: Fix build error unused-value
    
    commit 50d6281ce9b8412f7ef02d1bc9d23aa62ae0cf98 upstream.
    
    If CONFIG_DMA_DECLARE_COHERENT is not set,
    make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- will be failed, like this:
    
    drivers/remoteproc/remoteproc_core.c: In function ‘rproc_rvdev_release’:
    ./include/linux/dma-map-ops.h:182:42: error: statement with no effect [-Werror=unused-value]
     #define dma_release_coherent_memory(dev) (0)
                                              ^
    drivers/remoteproc/remoteproc_core.c:464:2: note: in expansion of macro ‘dma_release_coherent_memory’
      dma_release_coherent_memory(dev);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    
    The return type of function dma_release_coherent_memory in CONFIG_DMA_DECLARE_COHERENT area is void, so in !CONFIG_DMA_DECLARE_COHERENT area it should neither return any value nor be defined as zero.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: e61c451476e6 ("dma-mapping: Add dma_release_coherent_memory to DMA API")
    Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220630123528.251181-1-renzhijie2@huawei.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drivers/amd/pm: fix a use-after-free in kv_parse_power_table [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Fri Dec 15 00:24:58 2023 +0800

    drivers/amd/pm: fix a use-after-free in kv_parse_power_table
    
    [ Upstream commit 28dd788382c43b330480f57cd34cde0840896743 ]
    
    When ps allocated by kzalloc equals to NULL, kv_parse_power_table
    frees adev->pm.dpm.ps that allocated before. However, after the control
    flow goes through the following call chains:
    
    kv_parse_power_table
      |-> kv_dpm_init
            |-> kv_dpm_sw_init
                  |-> kv_dpm_fini
    
    The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
    first free in kv_parse_power_table and causes a use-after-free bug.
    
    Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: clk: zynqmp: calculate closest mux rate [+ + +]
Author: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Date:   Wed Nov 29 03:29:15 2023 -0800

    drivers: clk: zynqmp: calculate closest mux rate
    
    [ Upstream commit b782921ddd7f84f524723090377903f399fdbbcb ]
    
    Currently zynqmp clock driver is not calculating closest mux rate and
    because of that Linux is not setting proper frequency for CPU and
    not able to set given frequency for dynamic frequency scaling.
    
    E.g., In current logic initial acpu clock parent and frequency as below
    apll1                  0    0    0  2199999978    0     0  50000      Y
        acpu0_mux          0    0    0  2199999978    0     0  50000      Y
            acpu0_idiv1    0    0    0  2199999978    0     0  50000      Y
                acpu0      0    0    0  2199999978    0     0  50000      Y
    
    After changing acpu frequency to 549999994 Hz using CPU freq scaling its
    selecting incorrect parent which is not closest frequency.
    rpll_to_xpd            0    0    0  1599999984    0     0  50000      Y
        acpu0_mux          0    0    0  1599999984    0     0  50000      Y
            acpu0_div1     0    0    0   533333328    0     0  50000      Y
                acpu0      0    0    0   533333328    0     0  50000      Y
    
    Parent should remain same since 549999994 = 2199999978 / 4.
    
    So use __clk_mux_determine_rate_closest() generic function to calculate
    closest rate for mux clock. After this change its selecting correct
    parent and correct clock rate.
    apll1                  0    0    0  2199999978    0     0  50000      Y
        acpu0_mux          0    0    0  2199999978    0     0  50000      Y
            acpu0_div1     0    0    0   549999995    0     0  50000      Y
                acpu0      0    0    0   549999995    0     0  50000      Y
    
    Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
    Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
    Link: https://lore.kernel.org/r/20231129112916.23125-2-jay.buddhabhatti@amd.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers: clk: zynqmp: update divider round rate logic [+ + +]
Author: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Date:   Wed Nov 29 03:29:16 2023 -0800

    drivers: clk: zynqmp: update divider round rate logic
    
    [ Upstream commit 1fe15be1fb613534ecbac5f8c3f8744f757d237d ]
    
    Currently zynqmp divider round rate is considering single parent and
    calculating rate and parent rate accordingly. But if divider clock flag
    is set to SET_RATE_PARENT then its not trying to traverse through all
    parent rate and not selecting best parent rate from that. So use common
    divider_round_rate() which is traversing through all clock parents and
    its rate and calculating proper parent rate.
    
    Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
    Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
    Link: https://lore.kernel.org/r/20231129112916.23125-3-jay.buddhabhatti@amd.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: fix a double-free in si_dpm_init [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Dec 14 23:24:11 2023 +0800

    drm/amd/pm: fix a double-free in si_dpm_init
    
    [ Upstream commit ac16667237a82e2597e329eb9bc520d1cf9dff30 ]
    
    When the allocation of
    adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
    amdgpu_free_extended_power_table is called to free some fields of adev.
    However, when the control flow returns to si_dpm_sw_init, it goes to
    label dpm_failed and calls si_dpm_fini, which calls
    amdgpu_free_extended_power_table again and free those fields again. Thus
    a double-free is triggered.
    
    Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/debugfs: fix error code when smc register accessors are NULL [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Nov 27 17:26:29 2023 -0500

    drm/amdgpu/debugfs: fix error code when smc register accessors are NULL
    
    [ Upstream commit afe58346d5d3887b3e49ff623d2f2e471f232a8d ]
    
    Should be -EOPNOTSUPP.
    
    Fixes: 5104fdf50d32 ("drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL")
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Fix cat debugfs amdgpu_regs_didt causes kernel null pointer [+ + +]
Author: Lu Yao <yaolu@kylinos.cn>
Date:   Thu Nov 23 09:22:34 2023 +0800

    drm/amdgpu: Fix cat debugfs amdgpu_regs_didt causes kernel null pointer
    
    [ Upstream commit 2161e09cd05a50d80736fe397145340d2e8f6c05 ]
    
    For 'AMDGPU_FAMILY_SI' family cards, in 'si_common_early_init' func, init
    'didt_rreg' and 'didt_wreg' to 'NULL'. But in func
    'amdgpu_debugfs_regs_didt_read/write', using 'RREG32_DIDT' 'WREG32_DIDT'
    lacks of relevant judgment. And other 'amdgpu_ip_block_version' that use
    these two definitions won't be added for 'AMDGPU_FAMILY_SI'.
    
    So, add null pointer judgment before calling.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Lu Yao <yaolu@kylinos.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: Fix typo in post_disable() description [+ + +]
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Fri Nov 24 10:42:30 2023 +0100

    drm/bridge: Fix typo in post_disable() description
    
    [ Upstream commit 288b039db225676e0c520c981a1b5a2562d893a3 ]
    
    s/singals/signals/
    
    Fixes: 199e4e967af4 ("drm: Extract drm_bridge.h")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231124094253.658064-1-dario.binacchi@amarulasolutions.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358767: Fix return value on error case [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Nov 3 15:14:06 2023 +0200

    drm/bridge: tc358767: Fix return value on error case
    
    [ Upstream commit 32bd29b619638256c5b75fb021d6d9f12fc4a984 ]
    
    If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains
    0, instead of an error value.
    
    Return -EINVAL instead.
    
    Fixes: f25ee5017e4f ("drm/bridge: tc358767: add IRQ and HPD support")
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-4-c22b2444f5f5@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Nov 2 17:56:42 2023 +0100

    drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
    
    [ Upstream commit ce3e112e7ae854249d8755906acc5f27e1542114 ]
    
    With tpd12s015_remove() marked with __exit this function is discarded
    when the driver is compiled as a built-in. The result is that when the
    driver unbinds there is no cleanup done which results in resource
    leakage or worse.
    
    Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231102165640.3307820-19-u.kleine-koenig@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/crtc: Fix uninit-value bug in drm_mode_setcrtc [+ + +]
Author: Ziqi Zhao <astrajoan@yahoo.com>
Date:   Fri Jul 21 09:14:46 2023 -0700

    drm/crtc: Fix uninit-value bug in drm_mode_setcrtc
    
    [ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
    
    The connector_set contains uninitialized values when allocated with
    kmalloc_array. However, in the "out" branch, the logic assumes that any
    element in connector_set would be equal to NULL if failed to
    initialize, which causes the bug reported by Syzbot. The fix is to use
    an extra variable to keep track of how many connectors are initialized
    indeed, and use that variable to decrease any refcounts in the "out"
    branch.
    
    Reported-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Signed-off-by: Ziqi Zhao <astrajoan@yahoo.com>
    Reported-and-tested-by: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Link: https://lore.kernel.org/r/20230721161446.8602-1-astrajoan@yahoo.com
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/crtc: fix uninitialized variable use [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Dec 8 15:12:38 2023 +0200

    drm/crtc: fix uninitialized variable use
    
    [ Upstream commit 6e455f5dcdd15fa28edf0ffb5b44d3508512dccf ]
    
    Commit 3823119b9c2b ("drm/crtc: Fix uninit-value bug in
    drm_mode_setcrtc") was supposed to fix use of an uninitialized variable,
    but introduced another.
    
    num_connectors is only initialized if crtc_req->count_connectors > 0,
    but it's used regardless. Fix it.
    
    Fixes: 3823119b9c2b ("drm/crtc: Fix uninit-value bug in drm_mode_setcrtc")
    Cc: syzbot+4fad2e57beb6397ab2fc@syzkaller.appspotmail.com
    Cc: Ziqi Zhao <astrajoan@yahoo.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231208131238.2924571-1-jani.nikula@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/drv: propagate errors from drm_modeset_register_all() [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sun Dec 3 01:55:52 2023 +0300

    drm/drv: propagate errors from drm_modeset_register_all()
    
    [ Upstream commit 5f8dec200923a76dc57187965fd59c1136f5d085 ]
    
    In case the drm_modeset_register_all() function fails, its error code
    will be ignored. Instead make the drm_dev_register() bail out in case of
    such an error.
    
    Fixes: 79190ea2658a ("drm: Add callbacks for late registering")
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231202225552.1283638-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos: fix a potential error pointer dereference [+ + +]
Author: Xiang Yang <xiangyang3@huawei.com>
Date:   Sat Aug 12 14:27:48 2023 +0800

    drm/exynos: fix a potential error pointer dereference
    
    [ Upstream commit 73bf1c9ae6c054c53b8e84452c5e46f86dd28246 ]
    
    Smatch reports the warning below:
    drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
    error: 'crtc' dereferencing possible ERR_PTR()
    
    The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
    which can not be used directly. Fix this by checking the return value
    before using it.
    
    Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/exynos: fix a wrong error checking [+ + +]
Author: Inki Dae <inki.dae@samsung.com>
Date:   Wed Nov 1 18:36:51 2023 +0900

    drm/exynos: fix a wrong error checking
    
    [ Upstream commit 8d1b7809684c688005706125b804e1f9792d2b1b ]
    
    Fix a wrong error checking in exynos_drm_dma.c module.
    
    In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
    and iommu_get_domain_for_dev() functions are expected to return NULL as
    an error.
    
    However, the error checking is performed using the statement
    if(IS_ERR(mapping)), which doesn't provide a suitable error value.
    So check if 'mapping' is NULL, and if it is, return -ENODEV.
    
    This issue[1] was reported by Dan.
    
    Changelog v1:
    - fix build warning.
    
    [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
    
    Reported-by : Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jun 20 13:43:20 2023 +0200

    drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
    
    [ Upstream commit 3d07a411b4faaf2b498760ccf12888f8de529de0 ]
    
    This helper has been introduced to avoid programmer errors (missing
    _put calls leading to dangling refcnt) when using pm_runtime_get, use it.
    
    While at it, start checking the return value.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Fixes: 5c8290284402 ("drm/msm/dsi: Split PHY drivers to separate files")
    Patchwork: https://patchwork.freedesktop.org/patch/543350/
    Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-1-a11a751f34f0@linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/mdp4: flush vblank event on disable [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Nov 28 00:54:01 2023 +0300

    drm/msm/mdp4: flush vblank event on disable
    
    [ Upstream commit c6721b3c6423d8a348ae885a0f4c85e14f9bf85c ]
    
    Flush queued events when disabling the crtc. This avoids timeouts when
    we come back and wait for dependencies (like the previous frame's
    flip_done).
    
    Fixes: c8afe684c95c ("drm/msm: basic KMS driver for snapdragon")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/569127/
    Link: https://lore.kernel.org/r/20231127215401.4064128-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer [+ + +]
Author: Abhinav Singh <singhabhinav9051571833@gmail.com>
Date:   Tue Nov 14 00:43:03 2023 +0530

    drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer
    
    [ Upstream commit 5f35a624c1e30b5bae5023b3c256e94e0ad4f806 ]
    
    Fix a sparse warning with this message
    "warning:dereference of noderef expression". In this context it means we
    are dereferencing a __rcu tagged pointer directly.
    
    We should not be directly dereferencing a rcu pointer. To get a normal
    (non __rcu tagged pointer) from a __rcu tagged pointer we are using the
    function unrcu_pointer(...). The non __rcu tagged pointer then can be
    dereferenced just like a normal pointer.
    
    I tested with qemu with this command
    qemu-system-x86_64 \
            -m 2G \
            -smp 2 \
            -kernel bzImage \
            -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
            -drive file=bullseye.img,format=raw \
            -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
            -net nic,model=e1000 \
            -enable-kvm \
            -nographic \
            -pidfile vm.pid \
            2>&1 | tee vm.log
    with lockdep enabled.
    
    Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu")
    Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231113191303.3277733-1-singhabhinav9051571833@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel-elida-kd35t133: hold panel in reset for unprepare [+ + +]
Author: Chris Morgan <macromorgan@hotmail.com>
Date:   Fri Nov 17 13:44:02 2023 -0600

    drm/panel-elida-kd35t133: hold panel in reset for unprepare
    
    [ Upstream commit 03c5b2a5f6c39fe4e090346536cf1c14ee18b61e ]
    
    For devices like the Anbernic RG351M and RG351P the panel is wired to
    an always on regulator. When the device suspends and wakes up, there
    are some slight artifacts on the screen that go away over time. If
    instead we hold the panel in reset status after it is unprepared,
    this does not happen.
    
    Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133 panels")
    Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
    Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Link: https://lore.kernel.org/r/20231117194405.1386265-3-macroalpha82@gmail.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231117194405.1386265-3-macroalpha82@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon/dpm: fix a memleak in sumo_parse_power_table [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Mon Dec 4 16:57:56 2023 +0800

    drm/radeon/dpm: fix a memleak in sumo_parse_power_table
    
    [ Upstream commit 0737df9ed0997f5b8addd6e2b9699a8c6edba2e4 ]
    
    The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
    following error-handling path. However, in the error-handling of
    rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
    resulting in a memleak in this function.
    
    Fixes: 80ea2c129c76 ("drm/radeon/kms: add dpm support for sumo asics (v2)")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon/r100: Fix integer overflow issues in r100_cs_track_check() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Wed Nov 29 07:22:12 2023 -0800

    drm/radeon/r100: Fix integer overflow issues in r100_cs_track_check()
    
    [ Upstream commit b5c5baa458faa5430c445acd9a17481274d77ccf ]
    
    It may be possible, albeit unlikely, to encounter integer overflow
    during the multiplication of several unsigned int variables, the
    result being assigned to a variable 'size' of wider type.
    
    Prevent this potential behaviour by converting one of the multiples
    to unsigned long.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 0242f74d29df ("drm/radeon: clean up CS functions in r100.c")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon/r600_cs: Fix possible int overflows in r600_cs_check_reg() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Wed Nov 29 07:22:30 2023 -0800

    drm/radeon/r600_cs: Fix possible int overflows in r600_cs_check_reg()
    
    [ Upstream commit 39c960bbf9d9ea862398759e75736cfb68c3446f ]
    
    While improbable, there may be a chance of hitting integer
    overflow when the result of radeon_get_ib_value() gets shifted
    left.
    
    Avoid it by casting one of the operands to larger data type (u64).
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 1729dd33d20b ("drm/radeon/kms: r600 CS parser fixes")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon/trinity_dpm: fix a memleak in trinity_parse_power_table [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Mon Dec 4 18:21:54 2023 +0800

    drm/radeon/trinity_dpm: fix a memleak in trinity_parse_power_table
    
    [ Upstream commit 28c28d7f77c06ac2c0b8f9c82bc04eba22912b3b ]
    
    The rdev->pm.dpm.ps allocated by kcalloc should be freed in every
    following error-handling path. However, in the error-handling of
    rdev->pm.power_state[i].clock_info the rdev->pm.dpm.ps is not freed,
    resulting in a memleak in this function.
    
    Fixes: d70229f70447 ("drm/radeon/kms: add dpm support for trinity asics")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: check return value of radeon_ring_lock() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Tue Aug 8 11:04:16 2023 -0700

    drm/radeon: check return value of radeon_ring_lock()
    
    [ Upstream commit 71225e1c930942cb1e042fc08c5cc0c4ef30e95e ]
    
    In the unlikely event of radeon_ring_lock() failing, its errno return
    value should be processed. This patch checks said return value and
    prints a debug message in case of an error.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 48c0c902e2e6 ("drm/radeon/kms: add support for CP setup on SI")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Nov 30 15:50:16 2023 +0800

    drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()
    
    [ Upstream commit 7a2464fac80d42f6f8819fed97a553e9c2f43310 ]
    
    check the alloc_workqueue return value in radeon_crtc_init()
    to avoid null-ptr-deref.
    
    Fixes: fa7f517cb26e ("drm/radeon: rework page flip handling v4")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: clock: Update the videocc resets for sm8150 [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Fri Dec 1 15:20:24 2023 +0530

    dt-bindings: clock: Update the videocc resets for sm8150
    
    [ Upstream commit 3185f96968eedd117ec72ee7b87ead44b6d1bbbd ]
    
    Add all the available resets for the video clock controller
    on sm8150.
    
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20231201-videocc-8150-v3-1-56bec3a5e443@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Stable-dep-of: 1fd9a939db24 ("clk: qcom: videocc-sm8150: Update the videocc resets")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/thunderx: Fix possible out-of-bounds string access [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 22 23:19:53 2023 +0100

    EDAC/thunderx: Fix possible out-of-bounds string access
    
    [ Upstream commit 475c58e1a471e9b873e3e39958c64a2d278275c8 ]
    
    Enabling -Wstringop-overflow globally exposes a warning for a common bug
    in the usage of strncat():
    
      drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
      drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
       1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);
            |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ...
       1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
       ...
       1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
    
       ...
    
    Apparently the author of this driver expected strncat() to behave the
    way that strlcat() does, which uses the size of the destination buffer
    as its third argument rather than the length of the source buffer. The
    result is that there is no check on the size of the allocated buffer.
    
    Change it to strlcat().
    
      [ bp: Trim compiler output, fixup commit message. ]
    
    Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/20231122222007.3199885-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
efivarfs: force RO when remounting if SetVariable is not supported [+ + +]
Author: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date:   Tue Nov 7 14:40:56 2023 +0900

    efivarfs: force RO when remounting if SetVariable is not supported
    
    [ Upstream commit 0e8d2444168dd519fea501599d150e62718ed2fe ]
    
    If SetVariable at runtime is not supported by the firmware we never assign
    a callback for that function. At the same time mount the efivarfs as
    RO so no one can call that.  However, we never check the permission flags
    when someone remounts the filesystem as RW. As a result this leads to a
    crash looking like this:
    
    $ mount -o remount,rw /sys/firmware/efi/efivars
    $ efi-updatevar -f PK.auth PK
    
    [  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    [  303.280482] Mem abort info:
    [  303.280854]   ESR = 0x0000000086000004
    [  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
    [  303.282016]   SET = 0, FnV = 0
    [  303.282414]   EA = 0, S1PTW = 0
    [  303.282821]   FSC = 0x04: level 0 translation fault
    [  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
    [  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
    [  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
    [  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
    [  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
    [  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
    [  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  303.292123] pc : 0x0
    [  303.292443] lr : efivar_set_variable_locked+0x74/0xec
    [  303.293156] sp : ffff800008673c10
    [  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
    [  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
    [  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
    [  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
    [  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
    [  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
    [  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
    [  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
    [  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
    [  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
    [  303.303341] Call trace:
    [  303.303679]  0x0
    [  303.303938]  efivar_entry_set_get_size+0x98/0x16c
    [  303.304585]  efivarfs_file_write+0xd0/0x1a4
    [  303.305148]  vfs_write+0xc4/0x2e4
    [  303.305601]  ksys_write+0x70/0x104
    [  303.306073]  __arm64_sys_write+0x1c/0x28
    [  303.306622]  invoke_syscall+0x48/0x114
    [  303.307156]  el0_svc_common.constprop.0+0x44/0xec
    [  303.307803]  do_el0_svc+0x38/0x98
    [  303.308268]  el0_svc+0x2c/0x84
    [  303.308702]  el0t_64_sync_handler+0xf4/0x120
    [  303.309293]  el0t_64_sync+0x190/0x194
    [  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
    [  303.310612] ---[ end trace 0000000000000000 ]---
    
    Fix this by adding a .reconfigure() function to the fs operations which
    we can use to check the requested flags and deny anything that's not RO
    if the firmware doesn't implement SetVariable at runtime.
    
    Fixes: f88814cc2578 ("efi/efivars: Expose RT service availability via efivars abstraction")
    Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethtool: netlink: Add missing ethnl_ops_begin/complete [+ + +]
Author: Ludvig Pärsson <ludvig.parsson@axis.com>
Date:   Wed Jan 17 13:03:14 2024 +0100

    ethtool: netlink: Add missing ethnl_ops_begin/complete
    
    [ Upstream commit f1172f3ee3a98754d95b968968920a7d03fdebcc ]
    
    Accessing an ethernet device that is powered off or clock gated might
    cause the CPU to hang. Add ethnl_ops_begin/complete in
    ethnl_set_features() to protect against this.
    
    Fixes: 0980bfcd6954 ("ethtool: set netdev features with FEATURES_SET request")
    Signed-off-by: Ludvig Pärsson <ludvig.parsson@axis.com>
    Link: https://lore.kernel.org/r/20240117-etht2-v2-1-1a96b6e8c650@axis.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: explicitly null-terminate the xattr list [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Nov 6 20:44:34 2023 -0800

    f2fs: explicitly null-terminate the xattr list
    
    commit e26b6d39270f5eab0087453d9b544189a38c8564 upstream.
    
    When setting an xattr, explicitly null-terminate the xattr list.  This
    eliminates the fragile assumption that the unused xattr space is always
    zeroed.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
f2fs: fix to avoid dirent corruption [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Nov 28 17:25:16 2023 +0800

    f2fs: fix to avoid dirent corruption
    
    [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ]
    
    As Al reported in link[1]:
    
    f2fs_rename()
    ...
            if (old_dir != new_dir && !whiteout)
                    f2fs_set_link(old_inode, old_dir_entry,
                                            old_dir_page, new_dir);
            else
                    f2fs_put_page(old_dir_page, 0);
    
    You want correct inumber in the ".." link.  And cross-directory
    rename does move the source to new parent, even if you'd been asked
    to leave a whiteout in the old place.
    
    [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/
    
    With below testcase, it may cause dirent corruption, due to it missed
    to call f2fs_set_link() to update ".." link to new directory.
    - mkdir -p dir/foo
    - renameat2 -w dir/foo bar
    
    [ASSERT] (__chk_dots_dentries:1421)  --> Bad inode number[0x4] for '..', parent parent ino is [0x3]
    [FSCK] other corrupted bugs                           [Fail]
    
    Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT")
    Cc: Jan Kara <jack@suse.cz>
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Chao Yu <chao@kernel.org>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to check compress file in f2fs_move_file_range() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Dec 10 19:35:44 2023 +0800

    f2fs: fix to check compress file in f2fs_move_file_range()
    
    [ Upstream commit fb9b65340c818875ea86464faf3c744bdce0055c ]
    
    f2fs_move_file_range() doesn't support migrating compressed cluster
    data, let's add the missing check condition and return -EOPNOTSUPP
    for the case until we support it.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to update iostat correctly in f2fs_filemap_fault() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Dec 10 19:35:47 2023 +0800

    f2fs: fix to update iostat correctly in f2fs_filemap_fault()
    
    [ Upstream commit bb34cc6ca87ff78f9fb5913d7619dc1389554da6 ]
    
    In f2fs_filemap_fault(), it fixes to update iostat info only if
    VM_FAULT_LOCKED is tagged in return value of filemap_fault().
    
    Fixes: 8b83ac81f428 ("f2fs: support read iostat")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: flush deferred work in fb_deferred_io_fsync() [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Mon Dec 18 10:57:30 2023 +0100

    fbdev: flush deferred work in fb_deferred_io_fsync()
    
    commit 15e4c1f462279b4e128f27de48133e0debe9e0df upstream.
    
    The driver's fsync() is supposed to flush any pending operation to
    hardware. It is implemented in this driver by cancelling the queued
    deferred IO first, then schedule it for "immediate execution" by calling
    schedule_delayed_work() again with delay=0. However, setting delay=0
    only means the work is scheduled immediately, it does not mean the work
    is executed immediately. There is no guarantee that the work is finished
    after schedule_delayed_work() returns. After this driver's fsync()
    returns, there can still be pending work. Furthermore, if close() is
    called by users immediately after fsync(), the pending work gets
    cancelled and fsync() may do nothing.
    
    To ensure that the deferred IO completes, use flush_delayed_work()
    instead. Write operations to this driver either write to the device
    directly, or invoke schedule_delayed_work(); so by flushing the
    workqueue, it can be guaranteed that all previous writes make it to the
    device.
    
    Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: meson_sm: populate platform devices from sm device tree data [+ + +]
Author: Dmitry Rokosov <ddrokosov@sberdevices.ru>
Date:   Fri Mar 24 17:55:57 2023 +0300

    firmware: meson_sm: populate platform devices from sm device tree data
    
    [ Upstream commit e45f243409db98d610248c843b25435e7fb0baf3 ]
    
    In some meson boards, secure monitor device has children, for example,
    power secure controller. By default, secure monitor isn't the bus in terms
    of device tree subsystem, so the of_platform initialization code doesn't
    populate its device tree data. As a result, secure monitor's children
    aren't probed at all.
    
    Run the 'of_platform_populate()' routine manually to resolve such issues.
    
    Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Link: https://lore.kernel.org/r/20230324145557.27797-1-ddrokosov@sberdevices.ru
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Stable-dep-of: d8385d7433f9 ("firmware: meson-sm: unmap out_base shmem in error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Oct 30 11:12:26 2023 +0100

    firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create()
    
    [ Upstream commit 964946b88887089f447a9b6a28c39ee97dc76360 ]
    
    The ending NULL is not taken into account by strncat(), so switch to
    snprintf() to correctly build 'debug_name'.
    
    Using snprintf() also makes the code more readable.
    
    Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/7158db0a4d7b19855ddd542ec61b666973aad8dc.1698660720.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: indicate request originates from old mount API [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Wed Nov 22 12:17:37 2023 -0500

    fs: indicate request originates from old mount API
    
    [ Upstream commit f67d922edb4e95a4a56d07d5d40a76dd4f23a85b ]
    
    We already communicate to filesystems when a remount request comes from
    the old mount API as some filesystems choose to implement different
    behavior in the new mount API than the old mount API to e.g., take the
    chance to fix significant API bugs. Allow the same for regular mount
    requests.
    
    Fixes: b330966f79fb ("fuse: reject options on reconfigure via fsconfig(2)")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    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>

 
gfs2: Also reflect single-block allocations in rgd->rd_extfail_pt [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Oct 5 19:39:18 2020 +0200

    gfs2: Also reflect single-block allocations in rgd->rd_extfail_pt
    
    [ Upstream commit f38e998fbbb5da6a097ecd4b2700ba95eabab0c9 ]
    
    Pass a non-NULL minext to gfs2_rbm_find even for single-block allocations.  In
    gfs2_rbm_find, also set rgd->rd_extfail_pt when a single-block allocation
    fails in a resource group: there is no reason for treating that case
    differently.  In gfs2_reservation_check_and_update, only check how many free
    blocks we have if more than one block is requested; we already know there's at
    least one free block.
    
    In addition, when allocating N blocks fails in gfs2_rbm_find, we need to set
    rd_extfail_pt to N - 1 rather than N:  rd_extfail_pt defines the biggest
    allocation that might still succeed.
    
    Finally, reset rd_extfail_pt when updating the resource group statistics in
    update_rgrp_lvb, as we already do in gfs2_rgrp_bh_get.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: 8877243beafa ("gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump [+ + +]
Author: Osama Muhammad <osmtendev@gmail.com>
Date:   Mon Nov 6 21:21:29 2023 +0500

    gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
    
    [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ]
    
    Syzkaller has reported a NULL pointer dereference when accessing
    rgd->rd_rgl in gfs2_rgrp_dump().  This can happen when creating
    rgd->rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
    gfs2_rgrp_dump() to prevent that.
    
    Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d
    Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found")
    Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpu/drm/radeon: fix two memleaks in radeon_vm_init [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Fri Dec 15 00:58:42 2023 +0800

    gpu/drm/radeon: fix two memleaks in radeon_vm_init
    
    [ Upstream commit c2709b2d6a537ca0fa0f1da36fdaf07e48ef447d ]
    
    When radeon_bo_create and radeon_vm_clear_bo fail, the vm->page_tables
    allocated before need to be freed. However, neither radeon_vm_init
    itself nor its caller have done such deallocation.
    
    Fixes: 6d2f2944e95e ("drm/radeon: use normal BOs for the page tables v4")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: wacom: Correct behavior when processing some confidence == false touches [+ + +]
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Dec 19 13:33:43 2023 -0800

    HID: wacom: Correct behavior when processing some confidence == false touches
    
    commit 502296030ec6b0329e00f9fb15018e170cc63037 upstream.
    
    There appear to be a few different ways that Wacom devices can deal with
    confidence:
    
      1. If the device looses confidence in a touch, it will first clear
         the tipswitch flag in one report, and then clear the confidence
         flag in a second report. This behavior is used by e.g. DTH-2452.
    
      2. If the device looses confidence in a touch, it will clear both
         the tipswitch and confidence flags within the same report. This
         behavior is used by some AES devices.
    
      3. If the device looses confidence in a touch, it will clear *only*
         the confidence bit. The tipswitch bit will remain set so long as
         the touch is tracked. This behavior may be used in future devices.
    
    The driver does not currently handle situation 3 properly. Touches that
    loose confidence will remain "in prox" and essentially frozen in place
    until the tipswitch bit is finally cleared. Not only does this result
    in userspace seeing a stuck touch, but it also prevents pen arbitration
    from working properly (the pen won't send events until all touches are
    up, but we don't currently process events from non-confident touches).
    
    This commit centralizes the checking of the confidence bit in the
    wacom_wac_finger_slot() function and has 'prox' depend on it. In the
    case where situation 3 is encountered, the treat the touch as though
    it was removed, allowing both userspace and the pen arbitration to
    act normally.
    
    Signed-off-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Fixes: 7fb0413baa7f ("HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: rk3x: fix potential spinlock recursion on poll [+ + +]
Author: Jensen Huang <jensenhuang@friendlyarm.com>
Date:   Thu Dec 7 16:21:59 2023 +0800

    i2c: rk3x: fix potential spinlock recursion on poll
    
    [ Upstream commit 19cde9c92b8d3b7ee555d0da3bcb0232d3a784f4 ]
    
    Possible deadlock scenario (on reboot):
    rk3x_i2c_xfer_common(polling)
        -> rk3x_i2c_wait_xfer_poll()
            -> rk3x_i2c_irq(0, i2c);
                --> spin_lock(&i2c->lock);
                ...
            <rk3x i2c interrupt>
            -> rk3x_i2c_irq(0, i2c);
                --> spin_lock(&i2c->lock); (deadlock here)
    
    Store the IRQ number and disable/enable it around the polling transfer.
    This patch has been tested on NanoPC-T4.
    
    Signed-off-by: Jensen Huang <jensenhuang@friendlyarm.com>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: s3c24xx: fix read transfers in polling mode [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Nov 8 17:43:52 2023 +0100

    i2c: s3c24xx: fix read transfers in polling mode
    
    [ Upstream commit 0d9cf23ed55d7ba3ab26d617a3ae507863674c8f ]
    
    To properly handle read transfers in polling mode, no waiting for the ACK
    state is needed as it will never come. Just wait a bit to ensure start
    state is on the bus and continue processing next bytes.
    
    Fixes: 117053f77a5a ("i2c: s3c2410: Add polling mode support")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Chanho Park <chanho61.park@samsung.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: s3c24xx: fix transferring more than one message in polling mode [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Nov 8 17:43:53 2023 +0100

    i2c: s3c24xx: fix transferring more than one message in polling mode
    
    [ Upstream commit 990489e1042c6c5d6bccf56deca68f8dbeed8180 ]
    
    To properly handle ACK on the bus when transferring more than one
    message in polling mode, move the polling handling loop from
    s3c24xx_i2c_message_start() to s3c24xx_i2c_doxfer(). This way
    i2c_s3c_irq_nextbyte() is always executed till the end, properly
    acknowledging the IRQ bits and no recursive calls to
    i2c_s3c_irq_nextbyte() are made.
    
    While touching this, also fix finishing transfers in polling mode by
    using common code path and always waiting for the bus to become idle
    and disabled.
    
    Fixes: 117053f77a5a ("i2c: s3c2410: Add polling mode support")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/iser: Prevent invalidating wrong MR [+ + +]
Author: Sergey Gorenko <sergeygo@nvidia.com>
Date:   Tue Dec 19 09:23:11 2023 +0200

    IB/iser: Prevent invalidating wrong MR
    
    [ Upstream commit 2f1888281e67205bd80d3e8f54dbd519a9653f26 ]
    
    The iser_reg_resources structure has two pointers to MR but only one
    mr_valid field. The implementation assumes that we use only *sig_mr when
    pi_enable is true. Otherwise, we use only *mr. However, it is only
    sometimes correct. Read commands without protection information occur even
    when pi_enble is true. For example, the following SCSI commands have a
    Data-In buffer but never have protection information: READ CAPACITY (16),
    INQUIRY, MODE SENSE(6), MAINTENANCE IN. So, we use
    *sig_mr for some SCSI commands and *mr for the other SCSI commands.
    
    In most cases, it works fine because the remote invalidation is applied.
    However, there are two cases when the remote invalidation is not
    applicable.
     1. Small write commands when all data is sent as an immediate.
     2. The target does not support the remote invalidation feature.
    
    The lazy invalidation is used if the remote invalidation is impossible.
    Since, at the lazy invalidation, we always invalidate the MR we want to
    use, the wrong MR may be invalidated.
    
    To fix the issue, we need a field per MR that indicates the MR needs
    invalidation. Since the ib_mr structure already has such a field, let's
    use ib_mr.need_inval instead of iser_reg_resources.mr_valid.
    
    Fixes: b76a439982f8 ("IB/iser: Use IB_WR_REG_MR_INTEGRITY for PI handover")
    Link: https://lore.kernel.org/r/20231219072311.40989-1-sergeygo@nvidia.com
    Acked-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Signed-off-by: Sergey Gorenko <sergeygo@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ida: Fix crash in ida_free when the bitmap is empty [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Dec 21 16:53:57 2023 +0000

    ida: Fix crash in ida_free when the bitmap is empty
    
    [ Upstream commit af73483f4e8b6f5c68c9aa63257bdd929a9c194a ]
    
    The IDA usually detects double-frees, but that detection failed to
    consider the case when there are no nearby IDs allocated and so we have a
    NULL bitmap rather than simply having a clear bit.  Add some tests to the
    test-suite to be sure we don't inadvertently reintroduce this problem.
    Unfortunately they're quite noisy so include a message to disregard
    the warnings.
    
    Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: adc: ad7091r: Pass iio_dev to event handler [+ + +]
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
Date:   Sat Dec 16 14:46:11 2023 -0300

    iio: adc: ad7091r: Pass iio_dev to event handler
    
    commit a25a7df518fc71b1ba981d691e9322e645d2689c upstream.
    
    Previous version of ad7091r event handler received the ADC state pointer
    and retrieved the iio device from driver data field with dev_get_drvdata().
    However, no driver data have ever been set, which led to null pointer
    dereference when running the event handler.
    
    Pass the iio device to the event handler and retrieve the ADC state struct
    from it so we avoid the null pointer dereference and save the driver from
    filling the driver data field.
    
    Fixes: ca69300173b6 ("iio: adc: Add support for AD7091R5 ADC")
    Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
    Link: https://lore.kernel.org/r/5024b764107463de9578d5b3b0a3d5678e307b1a.1702746240.git.marcelo.schmitt1@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad9467: Benefit from devm_clk_get_enabled() to simplify [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Aug 8 22:47:30 2022 +0200

    iio: adc: ad9467: Benefit from devm_clk_get_enabled() to simplify
    
    [ Upstream commit cdd07b3ab94a020570132558442a26e74b70bc42 ]
    
    Make use of devm_clk_get_enabled() to replace some code that effectively
    open codes this new function.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20220808204740.307667-3-u.kleine-koenig@pengutronix.de
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 76f028539cf3 ("iio: adc: ad9467: fix reset gpio handling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: don't ignore error codes [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:25 2023 +0100

    iio: adc: ad9467: don't ignore error codes
    
    [ Upstream commit e072e149cfb827e0ab4cafb0547e9658e35393cd ]
    
    Make sure functions that return errors are not ignored.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-2-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: fix reset gpio handling [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:24 2023 +0100

    iio: adc: ad9467: fix reset gpio handling
    
    [ Upstream commit 76f028539cf360f750efd8cde560edda298e4c6b ]
    
    The reset gpio was being handled with inverted polarity. This means that
    as far as gpiolib is concerned we were actually leaving the pin asserted
    (in theory, this would mean reset). However, inverting the polarity in
    devicetree made things work. Fix it by doing it the proper way and how
    gpiolib expects it to be done.
    
    While at it, moved the handling to it's own function and dropped
    'reset_gpio' from the 'struct ad9467_state' as we only need it during
    probe. On top of that, refactored things so that we now request the gpio
    asserted (i.e in reset) and then de-assert it. Also note that we now use
    gpiod_set_value_cansleep() instead of gpiod_direction_output() as we
    already request the pin as output.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-1-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: fix scale setting [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:27 2023 +0100

    iio: adc: ad9467: fix scale setting
    
    [ Upstream commit b73f08bb7fe5a0901646ca5ceaa1e7a2d5ee6293 ]
    
    When reading in_voltage_scale we can get something like:
    
    root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale
    0.038146
    
    However, when reading the available options:
    
    root@analog:/sys/bus/iio/devices/iio:device2# cat
    in_voltage_scale_available
    2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010
    
    which does not make sense. Moreover, when trying to set a new scale we
    get an error because there's no call to __ad9467_get_scale() to give us
    values as given when reading in_voltage_scale. Fix it by computing the
    available scales during probe and properly pass the list when
    .read_available() is called.
    
    While at it, change to use .read_available() from iio_info. Also note
    that to properly fix this, adi-axi-adc.c has to be changed accordingly.
    
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-4-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: atkbd - skip ATKBD_CMD_GETID in translated mode [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Nov 24 19:59:24 2023 -0800

    Input: atkbd - skip ATKBD_CMD_GETID in translated mode
    
    [ Upstream commit 936e4d49ecbc8c404790504386e1422b599dec39 ]
    
    There have been multiple reports of keyboard issues on recent laptop models
    which can be worked around by setting i8042.dumbkbd, with the downside
    being this breaks the capslock LED.
    
    It seems that these issues are caused by recent laptops getting confused by
    ATKBD_CMD_GETID. Rather then adding and endless growing list of quirks for
    this, just skip ATKBD_CMD_GETID alltogether on laptops in translated mode.
    
    The main goal of sending ATKBD_CMD_GETID is to skip binding to ps/2
    mice/touchpads and those are never used in translated mode.
    
    Examples of laptop models which benefit from skipping ATKBD_CMD_GETID:
    
    * "HP Laptop 15s-fq2xxx", "HP laptop 15s-fq4xxx" and "HP Laptop 15-dy2xxx"
      models the kbd stops working for the first 2 - 5 minutes after boot
      (waiting for EC watchdog reset?)
    
    * On "HP Spectre x360 13-aw2xxx" atkbd fails to probe the keyboard
    
    * At least 9 different Lenovo models have issues with ATKBD_CMD_GETID, see:
      https://github.com/yescallop/atkbd-nogetid
    
    This has been tested on:
    
    1. A MSI B550M PRO-VDH WIFI desktop, where the i8042 controller is not
       in translated mode when no keyboard is plugged in and with a ps/2 kbd
       a "AT Translated Set 2 keyboard" /dev/input/event# node shows up
    
    2. A Lenovo ThinkPad X1 Yoga gen 8 (always has a translated set 2 keyboard)
    
    Reported-by: Shang Ye <yesh25@mail2.sysu.edu.cn>
    Closes: https://lore.kernel.org/linux-input/886D6167733841AE+20231017135318.11142-1-yesh25@mail2.sysu.edu.cn/
    Closes: https://github.com/yescallop/atkbd-nogetid
    Reported-by: gurevitch <mail@gurevit.ch>
    Closes: https://lore.kernel.org/linux-input/2iAJTwqZV6lQs26cTb38RNYqxvsink6SRmrZ5h0cBUSuf9NT0tZTsf9fEAbbto2maavHJEOP8GA1evlKa6xjKOsaskDhtJWxjcnrgPigzVo=@gurevit.ch/
    Reported-by: Egor Ignatov <egori@altlinux.org>
    Closes: https://lore.kernel.org/all/20210609073333.8425-1-egori@altlinux.org/
    Reported-by: Anton Zhilyaev <anton@cpp.in>
    Closes: https://lore.kernel.org/linux-input/20210201160336.16008-1-anton@cpp.in/
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2086156
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231115174625.7462-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: atkbd - use ab83 as id when skipping the getid command [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jan 16 21:43:25 2024 +0100

    Input: atkbd - use ab83 as id when skipping the getid command
    
    commit 58f65f9db7e0de366a5a115c2e2c0703858bba69 upstream.
    
    Barnabás reported that the change to skip the getid command
    when the controller is in translated mode on laptops caused
    the Version field of his "AT Translated Set 2 keyboard"
    input device to change from ab83 to abba, breaking a custom
    hwdb entry for this keyboard.
    
    Use the standard ab83 id for keyboards when getid is skipped
    (rather then that getid fails) to avoid reporting a different
    Version to userspace then before skipping the getid.
    
    Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
    Reported-by: Barnabás Pőcze <pobrn@protonmail.com>
    Closes: https://lore.kernel.org/linux-input/W1ydwoG2fYv85Z3C3yfDOJcVpilEvGge6UGa9kZh8zI2-qkHXp7WLnl2hSkFz63j-c7WupUWI5TLL6n7Lt8DjRuU-yJBwLYWrreb1hbnd6A=@protonmail.com/
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240116204325.7719-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: i8042 - add nomux quirk for Acer P459-G2-M [+ + +]
Author: Esther Shimanovich <eshimanovich@chromium.org>
Date:   Thu Nov 30 19:56:19 2023 +0000

    Input: i8042 - add nomux quirk for Acer P459-G2-M
    
    [ Upstream commit 335fe00319e030d481a54d5e0e68d50c5e672c0e ]
    
    After the laptop lid is opened, and the device resumes from S3 deep
    sleep, if the user presses a keyboard key while the screen is still black,
    the mouse and keyboard become unusable.
    
    Enabling this quirk prevents this behavior from occurring.
    
    Signed-off-by: Esther Shimanovich <eshimanovich@chromium.org>
    Link: https://lore.kernel.org/r/20231130195615.v2.1.Ibe78a9df97ecd18dc227a5cff67d3029631d9c11@changeid
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: xpad - add Razer Wolverine V2 support [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Sat Nov 25 17:22:15 2023 +0100

    Input: xpad - add Razer Wolverine V2 support
    
    [ Upstream commit c3d1610345b79cbe29ef6ca04a4780eff0d360c7 ]
    
    Add the VID and PID of Razer Wolverine V2 to xpad_device.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Link: https://lore.kernel.org/r/20231125-razer-wolverine-v2-v1-1-979fe9f9288e@z3ntu.xyz
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/rw: ensure io->bytes_done is always initialized [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Jan 22 12:30:07 2024 -0700

    io_uring/rw: ensure io->bytes_done is always initialized
    
    commit 0a535eddbe0dc1de4386046ab849f08aeb2f8faf upstream.
    
    If IOSQE_ASYNC is set and we fail importing an iovec for a readv or
    writev request, then we leave ->bytes_done uninitialized and hence the
    eventual failure CQE posted can potentially have a random res value
    rather than the expected -EINVAL.
    
    Setup ->bytes_done before potentially failing, so we have a consistent
    value if we fail the request early.
    
    Cc: stable@vger.kernel.org
    Reported-by: xingwei lee <xrivendell7@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/arm-smmu-qcom: Add missing GMU entry to match table [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Sun Dec 10 10:06:53 2023 -0800

    iommu/arm-smmu-qcom: Add missing GMU entry to match table
    
    commit afc95681c3068956fed1241a1ff1612c066c75ac upstream.
    
    In some cases the firmware expects cbndx 1 to be assigned to the GMU,
    so we also want the default domain for the GMU to be an identy domain.
    This way it does not get a context bank assigned.  Without this, both
    of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
    allocating and configuring a context bank.  So GMU ends up attached to
    both cbndx 1 and later cbndx 2.  This arrangement seemingly confounds
    and surprises the firmware if the GPU later triggers a translation
    fault, resulting (on sc8280xp / lenovo x13s, at least) in the SMMU
    getting wedged and the GPU stuck without memory access.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20231210180655.75542-1-robdclark@gmail.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 5 17:03:13 2024 +0000

    ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
    
    [ Upstream commit d375b98e0248980681e5e56b712026174d617198 ]
    
    syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
    
    Reading frag_off can only be done if we pulled enough bytes
    to skb->head. Currently we might access garbage.
    
    [1]
    BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
    ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
    ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
    ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
    __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
    netdev_start_xmit include/linux/netdevice.h:4954 [inline]
    xmit_one net/core/dev.c:3548 [inline]
    dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
    __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
    dev_queue_xmit include/linux/netdevice.h:3134 [inline]
    neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
    neigh_output include/net/neighbour.h:542 [inline]
    ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
    ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
    NF_HOOK_COND include/linux/netfilter.h:303 [inline]
    ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
    dst_output include/net/dst.h:451 [inline]
    ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
    ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
    ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
    rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
    rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
    inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
    ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
    __sys_sendmsg net/socket.c:2667 [inline]
    __do_sys_sendmsg net/socket.c:2676 [inline]
    __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
    slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
    slab_alloc_node mm/slub.c:3478 [inline]
    __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
    __do_kmalloc_node mm/slab_common.c:1006 [inline]
    __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
    kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
    pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
    __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
    pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
    pskb_may_pull include/linux/skbuff.h:2681 [inline]
    ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
    ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
    ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
    __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
    netdev_start_xmit include/linux/netdevice.h:4954 [inline]
    xmit_one net/core/dev.c:3548 [inline]
    dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
    __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
    dev_queue_xmit include/linux/netdevice.h:3134 [inline]
    neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
    neigh_output include/net/neighbour.h:542 [inline]
    ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
    ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
    NF_HOOK_COND include/linux/netfilter.h:303 [inline]
    ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
    dst_output include/net/dst.h:451 [inline]
    ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
    ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
    ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
    rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
    rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
    inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
    ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
    __sys_sendmsg net/socket.c:2667 [inline]
    __do_sys_sendmsg net/socket.c:2676 [inline]
    __se_sys_sendmsg net/socket.c:2674 [inline]
    __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    CPU: 0 PID: 7345 Comm: syz-executor.3 Not tainted 6.7.0-rc8-syzkaller-00024-gac865f00af29 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvs: avoid stat macros calls from preemptible context [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Jan 15 17:39:22 2024 +0300

    ipvs: avoid stat macros calls from preemptible context
    
    [ Upstream commit d6938c1c76c64f42363d0d1f051e1b4641c2ad40 ]
    
    Inside decrement_ttl() upon discovering that the packet ttl has exceeded,
    __IP_INC_STATS and __IP6_INC_STATS macros can be called from preemptible
    context having the following backtrace:
    
    check_preemption_disabled: 48 callbacks suppressed
    BUG: using __this_cpu_add() in preemptible [00000000] code: curl/1177
    caller is decrement_ttl+0x217/0x830
    CPU: 5 PID: 1177 Comm: curl Not tainted 6.7.0+ #34
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0xbd/0xe0
     check_preemption_disabled+0xd1/0xe0
     decrement_ttl+0x217/0x830
     __ip_vs_get_out_rt+0x4e0/0x1ef0
     ip_vs_nat_xmit+0x205/0xcd0
     ip_vs_in_hook+0x9b1/0x26a0
     nf_hook_slow+0xc2/0x210
     nf_hook+0x1fb/0x770
     __ip_local_out+0x33b/0x640
     ip_local_out+0x2a/0x490
     __ip_queue_xmit+0x990/0x1d10
     __tcp_transmit_skb+0x288b/0x3d10
     tcp_connect+0x3466/0x5180
     tcp_v4_connect+0x1535/0x1bb0
     __inet_stream_connect+0x40d/0x1040
     inet_stream_connect+0x57/0xa0
     __sys_connect_file+0x162/0x1a0
     __sys_connect+0x137/0x160
     __x64_sys_connect+0x72/0xb0
     do_syscall_64+0x6f/0x140
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    RIP: 0033:0x7fe6dbbc34e0
    
    Use the corresponding preemption-aware variants: IP_INC_STATS and
    IP6_INC_STATS.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 8d8e20e2d7bb ("ipvs: Decrement ttl")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jbd2: correct the printing of write_flags in jbd2_write_superblock() [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Wed Nov 29 19:47:39 2023 +0800

    jbd2: correct the printing of write_flags in jbd2_write_superblock()
    
    [ Upstream commit 85559227211020b270728104c3b89918f7af27ac ]
    
    The write_flags print in the trace of jbd2_write_superblock() is not
    real, so move the modification before the trace.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231129114740.2686201-1-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jbd2: fix soft lockup in journal_finish_inode_data_buffers() [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Dec 11 19:25:44 2023 +0800

    jbd2: fix soft lockup in journal_finish_inode_data_buffers()
    
    [ Upstream commit 6c02757c936063f0631b4e43fe156f8c8f1f351f ]
    
    There's issue when do io test:
    WARN: soft lockup - CPU#45 stuck for 11s! [jbd2/dm-2-8:4170]
    CPU: 45 PID: 4170 Comm: jbd2/dm-2-8 Kdump: loaded Tainted: G  OE
    Call trace:
     dump_backtrace+0x0/0x1a0
     show_stack+0x24/0x30
     dump_stack+0xb0/0x100
     watchdog_timer_fn+0x254/0x3f8
     __hrtimer_run_queues+0x11c/0x380
     hrtimer_interrupt+0xfc/0x2f8
     arch_timer_handler_phys+0x38/0x58
     handle_percpu_devid_irq+0x90/0x248
     generic_handle_irq+0x3c/0x58
     __handle_domain_irq+0x68/0xc0
     gic_handle_irq+0x90/0x320
     el1_irq+0xcc/0x180
     queued_spin_lock_slowpath+0x1d8/0x320
     jbd2_journal_commit_transaction+0x10f4/0x1c78 [jbd2]
     kjournald2+0xec/0x2f0 [jbd2]
     kthread+0x134/0x138
     ret_from_fork+0x10/0x18
    
    Analyzed informations from vmcore as follows:
    (1) There are about 5k+ jbd2_inode in 'commit_transaction->t_inode_list';
    (2) Now is processing the 855th jbd2_inode;
    (3) JBD2 task has TIF_NEED_RESCHED flag;
    (4) There's no pags in address_space around the 855th jbd2_inode;
    (5) There are some process is doing drop caches;
    (6) Mounted with 'nodioread_nolock' option;
    (7) 128 CPUs;
    
    According to informations from vmcore we know 'journal->j_list_lock' spin lock
    competition is fierce. So journal_finish_inode_data_buffers() maybe process
    slowly. Theoretically, there is scheduling point in the filemap_fdatawait_range_keep_errors().
    However, if inode's address_space has no pages which taged with PAGECACHE_TAG_WRITEBACK,
    will not call cond_resched(). So may lead to soft lockup.
    journal_finish_inode_data_buffers
      filemap_fdatawait_range_keep_errors
        __filemap_fdatawait_range
          while (index <= end)
            nr_pages = pagevec_lookup_range_tag(&pvec, mapping, &index, end, PAGECACHE_TAG_WRITEBACK);
            if (!nr_pages)
               break;    --> If 'nr_pages' is equal zero will break, then will not call cond_resched()
            for (i = 0; i < nr_pages; i++)
              wait_on_page_writeback(page);
            cond_resched();
    
    To solve above issue, add scheduling point in the journal_finish_inode_data_buffers();
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231211112544.3879780-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kdb: Fix a potential buffer overflow in kdb_local() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Nov 25 13:05:04 2023 +0100

    kdb: Fix a potential buffer overflow in kdb_local()
    
    [ Upstream commit 4f41d30cd6dc865c3cbc1a852372321eba6d4e4c ]
    
    When appending "[defcmd]" to 'kdb_prompt_str', the size of the string
    already in the buffer should be taken into account.
    
    An option could be to switch from strncat() to strlcat() which does the
    correct test to avoid such an overflow.
    
    However, this actually looks as dead code, because 'defcmd_in_progress'
    can't be true here.
    See a more detailed explanation at [1].
    
    [1]: https://lore.kernel.org/all/CAD=FV=WSh7wKN7Yp-3wWiDgX4E3isQ8uh0LCzTmd1v9Cg9j+nQ@mail.gmail.com/
    
    Fixes: 5d5314d6795f ("kdb: core for kgdb back end (1 of 2)")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
keys, dns: Fix size check of V1 server-list header [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jan 10 21:11:40 2024 +0000

    keys, dns: Fix size check of V1 server-list header
    
    commit acc657692aed438e9931438f8c923b2b107aebf9 upstream.
    
    Fix the size check added to dns_resolver_preparse() for the V1 server-list
    header so that it doesn't give EINVAL if the size supplied is the same as
    the size of the header struct (which should be valid).
    
    This can be tested with:
    
            echo -n -e '\0\0\01\xff\0\0' | keyctl padd dns_resolver desc @p
    
    which will give "add_key: Invalid argument" without this fix.
    
    Fixes: 1997b3cb4217 ("keys, dns: Fix missing size check of V1 server-list header")
    Reported-by: Pengfei Xu <pengfei.xu@intel.com>
    Link: https://lore.kernel.org/r/ZZ4fyY4r3rqgZL+4@xpf.sh.intel.com/
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Petr Vorel <pvorel@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kprobes: Fix to handle forcibly unoptimized kprobes on freeing_list [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Tue Feb 21 08:49:16 2023 +0900

    kprobes: Fix to handle forcibly unoptimized kprobes on freeing_list
    
    commit 4fbd2f83fda0ca44a2ec6421ca3508b355b31858 upstream.
    
    Since forcibly unoptimized kprobes will be put on the freeing_list directly
    in the unoptimize_kprobe(), do_unoptimize_kprobes() must continue to check
    the freeing_list even if unoptimizing_list is empty.
    
    This bug can happen if a kprobe is put in an instruction which is in the
    middle of the jump-replaced instruction sequence of an optprobe, *and* the
    optprobe is recently unregistered and queued on unoptimizing_list.
    In this case, the optprobe will be unoptimized forcibly (means immediately)
    and put it into the freeing_list, expecting the optprobe will be handled in
    do_unoptimize_kprobe().
    But if there is no other optprobes on the unoptimizing_list, current code
    returns from the do_unoptimize_kprobe() soon and does not handle the
    optprobe which is on the freeing_list. Then the optprobe will hit the
    WARN_ON_ONCE() in the do_free_cleaned_kprobes(), because it is not handled
    in the latter loop of the do_unoptimize_kprobe().
    
    To solve this issue, do not return from do_unoptimize_kprobes() immediately
    even if unoptimizing_list is empty.
    
    Moreover, this change affects another case. kill_optimized_kprobes() expects
    kprobe_optimizer() will just free the optprobe on freeing_list.
    So I changed it to just do list_move() to freeing_list if optprobes are on
    unoptimizing list. And the do_unoptimize_kprobe() will skip
    arch_disarm_kprobe() if the probe on freeing_list has gone flag.
    
    Link: https://lore.kernel.org/all/Y8URdIfVr3pq2X8w@xpf.sh.intel.com/
    Link: https://lore.kernel.org/all/167448024501.3253718.13037333683110512967.stgit@devnote3/
    
    Fixes: e4add247789e ("kprobes: Fix optimize_kprobe()/unoptimize_kprobe() cancellation logic")
    Reported-by: Pengfei Xu <pengfei.xu@intel.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Cc: stable@vger.kernel.org
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    [fp: adjust comment conflict regarding commit 223a76b268c9 ("kprobes: Fix
     coding style issues")]
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Thu Jan 4 18:32:32 2024 +0000

    KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
    
    commit ad362fe07fecf0aba839ff2cc59a3617bd42c33f upstream.
    
    There is a potential UAF scenario in the case of an LPI translation
    cache hit racing with an operation that invalidates the cache, such
    as a DISCARD ITS command. The root of the problem is that
    vgic_its_check_cache() does not elevate the refcount on the vgic_irq
    before dropping the lock that serializes refcount changes.
    
    Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
    and add the corresponding decrement after queueing the interrupt.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20240104183233.3560639-1-oliver.upton@linux.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: vgic-v4: Restore pending state on host userspace write [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Sun Dec 17 11:15:09 2023 +0000

    KVM: arm64: vgic-v4: Restore pending state on host userspace write
    
    commit 7b95382f965133ef61ce44aaabc518c16eb46909 upstream.
    
    When the VMM writes to ISPENDR0 to set the state pending state of
    an SGI, we fail to convey this to the HW if this SGI is already
    backed by a GICv4.1 vSGI.
    
    This is a bit of a corner case, as this would only occur if the
    vgic state is changed on an already running VM, but this can
    apparently happen across a guest reset driven by the VMM.
    
    Fix this by always writing out the pending_latch value to the
    HW, and reseting it to false.
    
    Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
    Cc: stable@vger.kernel.org # 5.10+
    Link: https://lore.kernel.org/r/7e7f2c0c-448b-10a9-8929-4b8f4f6e2a32@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
leds: aw2013: Select missing dependency REGMAP_I2C [+ + +]
Author: Dang Huynh <danct12@riseup.net>
Date:   Fri Nov 3 18:42:03 2023 +0700

    leds: aw2013: Select missing dependency REGMAP_I2C
    
    [ Upstream commit 75469bb0537ad2ab0fc1fb6e534a79cfc03f3b3f ]
    
    The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
    be selected.
    
    Otherwise build process may fail with:
      ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe':
        leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c'
    
    Signed-off-by: Dang Huynh <danct12@riseup.net>
    Acked-by: Nikita Travkin <nikita@trvn.ru>
    Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
    Link: https://lore.kernel.org/r/20231103114203.1108922-1-danct12@riseup.net
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libapi: Add missing linux/types.h header to get the __u64 type on io.h [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Nov 30 14:11:45 2023 -0300

    libapi: Add missing linux/types.h header to get the __u64 type on io.h
    
    [ Upstream commit af76b2dec0984a079d8497bfa37d29a9b55932e1 ]
    
    There are functions using __u64, so we need to have the linux/types.h
    header otherwise we'll break when its not included before api/io.h.
    
    Fixes: e95770af4c4a280f ("tools api: Add a lightweight buffered reading api")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/lkml/ZWjDPL+IzPPsuC3X@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.209 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 25 14:37:57 2024 -0800

    Linux 5.10.209
    
    Link: https://lore.kernel.org/r/20240122235732.009174833@linuxfoundation.org
    Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: cx231xx: fix a memleak in cx231xx_init_isoc [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Fri Dec 1 21:22:55 2023 +0800

    media: cx231xx: fix a memleak in cx231xx_init_isoc
    
    [ Upstream commit 5d3c8990e2bbf929cb211563dadd70708f42e4e6 ]
    
    The dma_q->p_left_data alloced by kzalloc should be freed in all the
    following error handling paths. However, it hasn't been freed in the
    allocation error paths of dev->video_mode.isoc_ctl.urb and
    dev->video_mode.isoc_ctl.transfer_buffer.
    
    On the other hand, the dma_q->p_left_data did be freed in the
    error-handling paths after that of dev->video_mode.isoc_ctl.urb and
    dev->video_mode.isoc_ctl.transfer_buffer, by calling
    cx231xx_uninit_isoc(dev). So the same free operation should be done in
    error-handling paths of those two allocation.
    
    Fixes: 64fbf4445526 ("[media] cx231xx: Added support for Carraera, Shelby, RDx_253S and VIDEO_GRABBER")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-frontends: m88ds3103: Fix a memory leak in an error handling path of m88ds3103_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Oct 30 08:20:26 2023 +0100

    media: dvb-frontends: m88ds3103: Fix a memory leak in an error handling path of m88ds3103_probe()
    
    [ Upstream commit 5b2f885e2f6f482d05c23f04c8240f7b4fc5bdb5 ]
    
    If an error occurs after a successful i2c_mux_add_adapter(), then
    i2c_mux_del_adapters() should be called to free some resources, as
    already done in the remove function.
    
    Fixes: e6089feca460 ("media: m88ds3103: Add support for ds3103b demod")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvbdev: drop refcount on error path in dvb_device_open() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Oct 31 12:53:33 2023 +0300

    media: dvbdev: drop refcount on error path in dvb_device_open()
    
    [ Upstream commit a2dd235df435a05d389240be748909ada91201d2 ]
    
    If call to file->f_op->open() fails, then call dvb_device_put(dvbdev).
    
    Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: pvrusb2: fix use after free on context disconnection [+ + +]
Author: Ricardo B. Marliere <ricardo@marliere.net>
Date:   Fri Oct 13 01:09:12 2023 +0200

    media: pvrusb2: fix use after free on context disconnection
    
    [ Upstream commit ded85b0c0edd8f45fec88783d7555a5b982449c1 ]
    
    Upon module load, a kthread is created targeting the
    pvr2_context_thread_func function, which may call pvr2_context_destroy
    and thus call kfree() on the context object. However, that might happen
    before the usb hub_event handler is able to notify the driver. This
    patch adds a sanity check before the invalid read reported by syzbot,
    within the context disconnection call stack.
    
    Reported-and-tested-by: syzbot+621409285c4156a009b3@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/000000000000a02a4205fff8eb92@google.com/
    
    Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload")
    Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
    Acked-by: Mike Isely <isely@pobox.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rkisp1: Disable runtime PM in probe error path [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Tue Jun 14 20:10:36 2022 +0100

    media: rkisp1: Disable runtime PM in probe error path
    
    [ Upstream commit 13c9810281f8b24af9b7712cd84a1fce61843e93 ]
    
    If the v4l2_device_register() call fails, runtime PM is left enabled.
    Fix it.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Dafna Hirschfeld <dafna@fastmail.com>
    Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Stable-dep-of: 452f604a4683 ("media: rkisp1: Fix media device memory leak")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mfd: syscon: Fix null pointer dereference in of_syscon_register() [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Mon Dec 4 17:24:43 2023 +0800

    mfd: syscon: Fix null pointer dereference in of_syscon_register()
    
    [ Upstream commit 41673c66b3d0c09915698fec5c13b24336f18dd1 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20231204092443.2462115-1-chentao@kylinos.cn
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Alchemy: Fix an out-of-bound access in db1200_dev_setup() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jan 10 19:07:36 2024 +0100

    MIPS: Alchemy: Fix an out-of-bound access in db1200_dev_setup()
    
    [ Upstream commit 89c4b588d11e9acf01d604de4b0c715884f59213 ]
    
    When calling spi_register_board_info(), we should pass the number of
    elements in 'db1200_spi_devs', not 'db1200_i2c_devs'.
    
    Fixes: 63323ec54a7e ("MIPS: Alchemy: Extended DB1200 board support.")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: Alchemy: Fix an out-of-bound access in db1550_dev_setup() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Jan 10 19:09:46 2024 +0100

    MIPS: Alchemy: Fix an out-of-bound access in db1550_dev_setup()
    
    [ Upstream commit 3c1e5abcda64bed0c7bffa65af2316995f269a61 ]
    
    When calling spi_register_board_info(),
    
    Fixes: f869d42e580f ("MIPS: Alchemy: Improved DB1550 support, with audio and serial busses.")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mips: dmi: Fix early remap on MIPS32 [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Sat Dec 2 14:14:18 2023 +0300

    mips: dmi: Fix early remap on MIPS32
    
    [ Upstream commit 0d0a3748a2cb38f9da1f08d357688ebd982eb788 ]
    
    dmi_early_remap() has been defined as ioremap_cache() which on MIPS32 gets
    to be converted to the VM-based mapping. DMI early remapping is performed
    at the setup_arch() stage with no VM available. So calling the
    dmi_early_remap() for MIPS32 causes the system to crash at the early boot
    time. Fix that by converting dmi_early_remap() to the uncached remapping
    which is always available on both 32 and 64-bits MIPS systems.
    
    Note this change shall not cause any regressions on the current DMI
    support implementation because on the early boot-up stage neither MIPS32
    nor MIPS64 has the cacheable ioremapping support anyway.
    
    Fixes: be8fa1cb444c ("MIPS: Add support for Desktop Management Interface (DMI)")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mips: Fix incorrect max_low_pfn adjustment [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Sat Dec 2 14:14:19 2023 +0300

    mips: Fix incorrect max_low_pfn adjustment
    
    [ Upstream commit 0f5cc249ff73552d3bd864e62f85841dafaa107d ]
    
    max_low_pfn variable is incorrectly adjusted if the kernel is built with
    high memory support and the later is detected in a running system, so the
    memory which actually can be directly mapped is getting into the highmem
    zone. See the ZONE_NORMAL range on my MIPS32r5 system:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x0000000007ffffff]
    >   HighMem  [mem 0x0000000008000000-0x000000020fffffff]
    
    while the zones are supposed to look as follows:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x000000001fffffff]
    >   HighMem  [mem 0x0000000020000000-0x000000020fffffff]
    
    Even though the physical memory within the range [0x08000000;0x20000000]
    belongs to MMIO on our system, we don't really want it to be considered as
    high memory since on MIPS32 that range still can be directly mapped.
    
    Note there might be other problems caused by the max_low_pfn variable
    misconfiguration. For instance high_memory variable is initialize with
    virtual address corresponding to the max_low_pfn PFN, and by design it
    must define the upper bound on direct map memory, then end of the normal
    zone. That in its turn potentially may cause problems in accessing the
    memory by means of the /dev/mem and /dev/kmem devices.
    
    Let's fix the discovered misconfiguration then. It turns out the commit
    a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") didn't introduce the
    max_low_pfn adjustment quite correct. If the kernel is built with high
    memory support and the system is equipped with high memory, the
    max_low_pfn variable will need to be initialized with PFN of the most
    upper directly reachable memory address so the zone normal would be
    correctly setup. On MIPS that PFN corresponds to PFN_DOWN(HIGHMEM_START).
    If the system is built with no high memory support and one is detected in
    the running system, we'll just need to adjust the max_pfn variable to
    discard the found high memory from the system and leave the max_low_pfn as
    is, since the later will be less than PFN_DOWN(HIGHMEM_START) anyway by
    design of the for_each_memblock() loop performed a bit early in the
    bootmem_init() method.
    
    Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mlxsw: spectrum: Use 'bitmap_zalloc()' when applicable [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Oct 24 21:17:51 2021 +0200

    mlxsw: spectrum: Use 'bitmap_zalloc()' when applicable
    
    [ Upstream commit 2c087dfcc9d5e7e8557d217f01f58ba42d1ddbf1 ]
    
    Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid
    some open-coded arithmetic in allocator arguments.
    
    Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
    consistency.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 483ae90d8f97 ("mlxsw: spectrum_acl_tcam: Fix stack corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure [+ + +]
Author: Amit Cohen <amcohen@nvidia.com>
Date:   Wed Jan 17 16:04:16 2024 +0100

    mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure
    
    [ Upstream commit 6d6eeabcfaba2fcadf5443b575789ea606f9de83 ]
    
    Lately, a bug was found when many TC filters are added - at some point,
    several bugs are printed to dmesg [1] and the switch is crashed with
    segmentation fault.
    
    The issue starts when gen_pool_free() fails because of unexpected
    behavior - a try to free memory which is already freed, this leads to BUG()
    call which crashes the switch and makes many other bugs.
    
    Trying to track down the unexpected behavior led to a bug in eRP code. The
    function mlxsw_sp_acl_erp_table_alloc() gets a pointer to the allocated
    index, sets the value and returns an error code. When gen_pool_alloc()
    fails it returns address 0, we track it and return -ENOBUFS outside, BUT
    the call for gen_pool_alloc() already override the index in erp_table
    structure. This is a problem when such allocation is done as part of
    table expansion. This is not a new table, which will not be used in case
    of allocation failure. We try to expand eRP table and override the
    current index (non-zero) with zero. Then, it leads to an unexpected
    behavior when address 0 is freed twice. Note that address 0 is valid in
    erp_table->base_index and indeed other tables use it.
    
    gen_pool_alloc() fails in case that there is no space left in the
    pre-allocated pool, in our case, the pool is limited to
    ACL_MAX_ERPT_BANK_SIZE, which is read from hardware. When more than max
    erp entries are required, we exceed the limit and return an error, this
    error leads to "Failed to migrate vregion" print.
    
    Fix this by changing erp_table->base_index only in case of a successful
    allocation.
    
    Add a test case for such a scenario. Without this fix it causes
    segmentation fault:
    
    $ TESTS="max_erp_entries_test" ./tc_flower.sh
    ./tc_flower.sh: line 988:  1560 Segmentation fault      tc filter del dev $h2 ingress chain $i protocol ip pref $i handle $j flower &>/dev/null
    
    [1]:
    kernel BUG at lib/genalloc.c:508!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 6 PID: 3531 Comm: tc Not tainted 6.7.0-rc5-custom-ga6893f479f5e #1
    Hardware name: Mellanox Technologies Ltd. MSN4700/VMOD0010, BIOS 5.11 07/12/2021
    RIP: 0010:gen_pool_free_owner+0xc9/0xe0
    ...
    Call Trace:
     <TASK>
     __mlxsw_sp_acl_erp_table_other_dec+0x70/0xa0 [mlxsw_spectrum]
     mlxsw_sp_acl_erp_mask_destroy+0xf5/0x110 [mlxsw_spectrum]
     objagg_obj_root_destroy+0x18/0x80 [objagg]
     objagg_obj_destroy+0x12c/0x130 [objagg]
     mlxsw_sp_acl_erp_mask_put+0x37/0x50 [mlxsw_spectrum]
     mlxsw_sp_acl_ctcam_region_entry_remove+0x74/0xa0 [mlxsw_spectrum]
     mlxsw_sp_acl_ctcam_entry_del+0x1e/0x40 [mlxsw_spectrum]
     mlxsw_sp_acl_tcam_ventry_del+0x78/0xd0 [mlxsw_spectrum]
     mlxsw_sp_flower_destroy+0x4d/0x70 [mlxsw_spectrum]
     mlxsw_sp_flow_block_cb+0x73/0xb0 [mlxsw_spectrum]
     tc_setup_cb_destroy+0xc1/0x180
     fl_hw_destroy_filter+0x94/0xc0 [cls_flower]
     __fl_delete+0x1ac/0x1c0 [cls_flower]
     fl_destroy+0xc2/0x150 [cls_flower]
     tcf_proto_destroy+0x1a/0xa0
    ...
    mlxsw_spectrum3 0000:07:00.0: Failed to migrate vregion
    mlxsw_spectrum3 0000:07:00.0: Failed to migrate vregion
    
    Fixes: f465261aa105 ("mlxsw: spectrum_acl: Implement common eRP core")
    Signed-off-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/4cfca254dfc0e5d283974801a24371c7b6db5989.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Add missing mutex_destroy() [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Feb 6 16:39:19 2023 +0100

    mlxsw: spectrum_acl_tcam: Add missing mutex_destroy()
    
    [ Upstream commit 65823e07b1e4055b6278725fd92f4d7e6f8d53fd ]
    
    Pair mutex_init() with a mutex_destroy() in the error path. Found during
    code review. No functional changes.
    
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 483ae90d8f97 ("mlxsw: spectrum_acl_tcam: Fix stack corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Fix stack corruption [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Jan 17 16:04:18 2024 +0100

    mlxsw: spectrum_acl_tcam: Fix stack corruption
    
    [ Upstream commit 483ae90d8f976f8339cf81066312e1329f2d3706 ]
    
    When tc filters are first added to a net device, the corresponding local
    port gets bound to an ACL group in the device. The group contains a list
    of ACLs. In turn, each ACL points to a different TCAM region where the
    filters are stored. During forwarding, the ACLs are sequentially
    evaluated until a match is found.
    
    One reason to place filters in different regions is when they are added
    with decreasing priorities and in an alternating order so that two
    consecutive filters can never fit in the same region because of their
    key usage.
    
    In Spectrum-2 and newer ASICs the firmware started to report that the
    maximum number of ACLs in a group is more than 16, but the layout of the
    register that configures ACL groups (PAGT) was not updated to account
    for that. It is therefore possible to hit stack corruption [1] in the
    rare case where more than 16 ACLs in a group are required.
    
    Fix by limiting the maximum ACL group size to the minimum between what
    the firmware reports and the maximum ACLs that fit in the PAGT register.
    
    Add a test case to make sure the machine does not crash when this
    condition is hit.
    
    [1]
    Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
    [...]
     dump_stack_lvl+0x36/0x50
     panic+0x305/0x330
     __stack_chk_fail+0x15/0x20
     mlxsw_sp_acl_tcam_group_update+0x116/0x120
     mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
     mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
     mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
     mlxsw_sp_acl_rule_add+0x47/0x240
     mlxsw_sp_flower_replace+0x1a9/0x1d0
     tc_setup_cb_add+0xdc/0x1c0
     fl_hw_replace_filter+0x146/0x1f0
     fl_change+0xc17/0x1360
     tc_new_tfilter+0x472/0xb90
     rtnetlink_rcv_msg+0x313/0x3b0
     netlink_rcv_skb+0x58/0x100
     netlink_unicast+0x244/0x390
     netlink_sendmsg+0x1e4/0x440
     ____sys_sendmsg+0x164/0x260
     ___sys_sendmsg+0x9a/0xe0
     __sys_sendmsg+0x7a/0xc0
     do_syscall_64+0x40/0xe0
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
    Reported-by: Orel Hagag <orelh@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/2d91c89afba59c22587b444994ae419dbea8d876.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Make fini symmetric to init [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Feb 6 16:39:20 2023 +0100

    mlxsw: spectrum_acl_tcam: Make fini symmetric to init
    
    [ Upstream commit 61fe3b9102ac84ba479ab84d8f5454af2e21e468 ]
    
    Move mutex_destroy() to the end to make the function symmetric with
    mlxsw_sp_acl_tcam_init(). No functional changes.
    
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 483ae90d8f97 ("mlxsw: spectrum_acl_tcam: Fix stack corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxsw: spectrum_acl_tcam: Reorder functions to avoid forward declarations [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Feb 6 16:39:21 2023 +0100

    mlxsw: spectrum_acl_tcam: Reorder functions to avoid forward declarations
    
    [ Upstream commit 194ab9476089bbfc021073214e071a404e375ee6 ]
    
    Move the initialization and de-initialization code further below in
    order to avoid forward declarations in the next patch. No functional
    changes.
    
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 483ae90d8f97 ("mlxsw: spectrum_acl_tcam: Fix stack corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: sdhci_am654: Fix TI SoC dependencies [+ + +]
Author: Peter Robinson <pbrobinson@gmail.com>
Date:   Wed Dec 20 13:59:46 2023 +0000

    mmc: sdhci_am654: Fix TI SoC dependencies
    
    [ Upstream commit cb052da7f031b0d2309a4895ca236afb3b4bbf50 ]
    
    The sdhci_am654 is specific to recent TI SoCs, update the
    dependencies for those SoCs and compile testing. While we're
    at it update the text to reflect the wider range of
    supported TI SoCS the driver now supports.
    
    Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
    Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
    Link: https://lore.kernel.org/r/20231220135950.433588-1-pbrobinson@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_omap: Fix TI SoC dependencies [+ + +]
Author: Peter Robinson <pbrobinson@gmail.com>
Date:   Wed Dec 20 13:59:47 2023 +0000

    mmc: sdhci_omap: Fix TI SoC dependencies
    
    [ Upstream commit 09f164d393a6671e5ff8342ba6b3cb7fe3f20208 ]
    
    The sdhci_omap is specific to  older TI SoCs, update the
    dependencies for those SoCs and compile testing. While we're
    at it update the text to reflect the wider range of
    supported TI SoCS the driver now supports.
    
    Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
    Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
    Link: https://lore.kernel.org/r/20231220135950.433588-2-pbrobinson@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: fix uninit-value in mptcp_incoming_options [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Thu Nov 23 09:23:39 2023 +0800

    mptcp: fix uninit-value in mptcp_incoming_options
    
    [ Upstream commit 237ff253f2d4f6307b7b20434d7cbcc67693298b ]
    
    Added initialization use_ack to mptcp_parse_option().
    
    Reported-by: syzbot+b834a6b2decad004cfa1@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier [+ + +]
Author: ZhaoLong Wang <wangzhaolong1@huawei.com>
Date:   Wed Dec 20 10:46:19 2023 +0800

    mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
    
    [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ]
    
    If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
    triggers NULL pointer dereference when trying to access
    ‘gluebi->desc’ in gluebi_read().
    
    ubi_gluebi_init
      ubi_register_volume_notifier
        ubi_enumerate_volumes
          ubi_notify_all
            gluebi_notify    nb->notifier_call()
              gluebi_create
                mtd_device_register
                  mtd_device_parse_register
                    add_mtd_device
                      blktrans_notify_add   not->add()
                        ftl_add_mtd         tr->add_mtd()
                          scan_header
                            mtd_read
                              mtd_read_oob
                                mtd_read_oob_std
                                  gluebi_read   mtd->read()
                                    gluebi->desc - NULL
    
    Detailed reproduction information available at the Link [1],
    
    In the normal case, obtain gluebi->desc in the gluebi_get_device(),
    and access gluebi->desc in the gluebi_read(). However,
    gluebi_get_device() is not executed in advance in the
    ftl_add_mtd() process, which leads to NULL pointer dereference.
    
    The solution for the gluebi module is to run jffs2 on the UBI
    volume without considering working with ftl or mtdblock [2].
    Therefore, this problem can be avoided by preventing gluebi from
    creating the mtdblock device after creating mtd partition of the
    type MTD_UBIVOLUME.
    
    Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1]
    Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@nod.at/ [2]
    Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Acked-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response [+ + +]
Author: Ronald Monthero <debug.penguin32@gmail.com>
Date:   Sat Nov 18 18:31:51 2023 +1000

    mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response
    
    [ Upstream commit 923fb6238cb3ac529aa2bf13b3b1e53762186a8b ]
    
    Under heavy load it is likely that the controller is done
    with its own task but the thread unlocking the wait is not
    scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the
    controller to respond within allowable timeslice of 1 sec.
    
    fsl,ifc-nand 7e800000.nand: Controller is not responding
    
    [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a)
    [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c)
    [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c)
    [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
    
    Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Ronald Monthero <debug.penguin32@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20231118083156.776887-1-debug.penguin32@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ncsi: internal.h: Fix a spello [+ + +]
Author: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Date:   Sat Mar 27 04:42:47 2021 +0530

    ncsi: internal.h: Fix a spello
    
    [ Upstream commit 195a8ec4033b4124f6864892e71dcef24ba74a5a ]
    
    s/Firware/Firmware/
    
    Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 3084b58bfd0b ("net/ncsi: Fix netlink major/minor version numbers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
neighbour: Don't let neigh_forced_gc() disable preemption for long [+ + +]
Author: Judy Hsiao <judyhsiao@chromium.org>
Date:   Wed Dec 6 03:38:33 2023 +0000

    neighbour: Don't let neigh_forced_gc() disable preemption for long
    
    [ Upstream commit e5dc5afff62f3e97e86c3643ec9fcad23de4f2d3 ]
    
    We are seeing cases where neigh_cleanup_and_release() is called by
    neigh_forced_gc() many times in a row with preemption turned off.
    When running on a low powered CPU at a low CPU frequency, this has
    been measured to keep preemption off for ~10 ms. That's not great on a
    system with HZ=1000 which expects tasks to be able to schedule in
    with ~1ms latency.
    
    Suggested-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ncsi: Fix netlink major/minor version numbers [+ + +]
Author: Peter Delevoryas <peter@pjd.dev>
Date:   Tue Nov 14 10:07:34 2023 -0600

    net/ncsi: Fix netlink major/minor version numbers
    
    [ Upstream commit 3084b58bfd0b9e4b5e034f31f31b42977db35f12 ]
    
    The netlink interface for major and minor version numbers doesn't actually
    return the major and minor version numbers.
    
    It reports a u32 that contains the (major, minor, update, alpha1)
    components as the major version number, and then alpha2 as the minor
    version number.
    
    For whatever reason, the u32 byte order was reversed (ntohl): maybe it was
    assumed that the encoded value was a single big-endian u32, and alpha2 was
    the minor version.
    
    The correct way to get the supported NC-SI version from the network
    controller is to parse the Get Version ID response as described in 8.4.44
    of the NC-SI spec[1].
    
        Get Version ID Response Packet Format
    
                  Bits
                +--------+--------+--------+--------+
         Bytes  | 31..24 | 23..16 | 15..8  | 7..0   |
        +-------+--------+--------+--------+--------+
        | 0..15 | NC-SI Header                      |
        +-------+--------+--------+--------+--------+
        | 16..19| Response code   | Reason code     |
        +-------+--------+--------+--------+--------+
        |20..23 | Major  | Minor  | Update | Alpha1 |
        +-------+--------+--------+--------+--------+
        |24..27 |         reserved         | Alpha2 |
        +-------+--------+--------+--------+--------+
        |            .... other stuff ....          |
    
    The major, minor, and update fields are all binary-coded decimal (BCD)
    encoded [2]. The spec provides examples below the Get Version ID response
    format in section 8.4.44.1, but for practical purposes, this is an example
    from a live network card:
    
        root@bmc:~# ncsi-util 0x15
        NC-SI Command Response:
        cmd: GET_VERSION_ID(0x15)
        Response: COMMAND_COMPLETED(0x0000)  Reason: NO_ERROR(0x0000)
        Payload length = 40
    
        20: 0xf1 0xf1 0xf0 0x00 <<<<<<<<< (major, minor, update, alpha1)
        24: 0x00 0x00 0x00 0x00 <<<<<<<<< (_, _, _, alpha2)
    
        28: 0x6d 0x6c 0x78 0x30
        32: 0x2e 0x31 0x00 0x00
        36: 0x00 0x00 0x00 0x00
        40: 0x16 0x1d 0x07 0xd2
        44: 0x10 0x1d 0x15 0xb3
        48: 0x00 0x17 0x15 0xb3
        52: 0x00 0x00 0x81 0x19
    
    This should be parsed as "1.1.0".
    
    "f" in the upper-nibble means to ignore it, contributing zero.
    
    If both nibbles are "f", I think the whole field is supposed to be ignored.
    Major and minor are "required", meaning they're not supposed to be "ff",
    but the update field is "optional" so I think it can be ff. I think the
    simplest thing to do is just set the major and minor to zero instead of
    juggling some conditional logic or something.
    
    bcd2bin() from "include/linux/bcd.h" seems to assume both nibbles are 0-9,
    so I've provided a custom BCD decoding function.
    
    Alpha1 and alpha2 are ISO/IEC 8859-1 encoded, which just means ASCII
    characters as far as I can tell, although the full encoding table for
    non-alphabetic characters is slightly different (I think).
    
    I imagine the alpha fields are just supposed to be alphabetic characters,
    but I haven't seen any network cards actually report a non-zero value for
    either.
    
    If people wrote software against this netlink behavior, and were parsing
    the major and minor versions themselves from the u32, then this would
    definitely break their code.
    
    [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.0.0.pdf
    [2] https://en.wikipedia.org/wiki/Binary-coded_decimal
    [2] https://en.wikipedia.org/wiki/ISO/IEC_8859-1
    
    Signed-off-by: Peter Delevoryas <peter@pjd.dev>
    Fixes: 138635cc27c9 ("net/ncsi: NCSI response packet handler")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/tg3: fix race condition in tg3_reset_task() [+ + +]
Author: Thinh Tran <thinhtr@linux.vnet.ibm.com>
Date:   Thu Nov 30 18:19:11 2023 -0600

    net/tg3: fix race condition in tg3_reset_task()
    
    [ Upstream commit 16b55b1f2269962fb6b5154b8bf43f37c9a96637 ]
    
    When an EEH error is encountered by a PCI adapter, the EEH driver
    modifies the PCI channel's state as shown below:
    
       enum {
          /* I/O channel is in normal state */
          pci_channel_io_normal = (__force pci_channel_state_t) 1,
    
          /* I/O to channel is blocked */
          pci_channel_io_frozen = (__force pci_channel_state_t) 2,
    
          /* PCI card is dead */
          pci_channel_io_perm_failure = (__force pci_channel_state_t) 3,
       };
    
    If the same EEH error then causes the tg3 driver's transmit timeout
    logic to execute, the tg3_tx_timeout() function schedules a reset
    task via tg3_reset_task_schedule(), which may cause a race condition
    between the tg3 and EEH driver as both attempt to recover the HW via
    a reset action.
    
    EEH driver gets error event
    --> eeh_set_channel_state()
        and set device to one of
        error state above           scheduler: tg3_reset_task() get
                                    returned error from tg3_init_hw()
                                 --> dev_close() shuts down the interface
    tg3_io_slot_reset() and
    tg3_io_resume() fail to
    reset/resume the device
    
    To resolve this issue, we avoid the race condition by checking the PCI
    channel state in the tg3_reset_task() function and skip the tg3 driver
    initiated reset when the PCI channel is not in the normal state.  (The
    driver has no access to tg3 device registers at this point and cannot
    even complete the reset task successfully without external assistance.)
    We'll leave the reset procedure to be managed by the EEH driver which
    calls the tg3_io_error_detected(), tg3_io_slot_reset() and
    tg3_io_resume() functions as appropriate.
    
    Adding the same checking in tg3_dump_state() to avoid dumping all
    device registers when the PCI channel is not in the normal state.
    
    Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com>
    Tested-by: Venkata Sai Duggi <venkata.sai.duggi@ibm.com>
    Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20231201001911.656-1-thinhtr@linux.vnet.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probe [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 11 15:20:18 2024 +0800

    net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probe
    
    [ Upstream commit 776dac5a662774f07a876b650ba578d0a62d20db ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240111072018.75971-1-chentao@kylinos.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk_eth_soc: remove duplicate if statements [+ + +]
Author: Chukun Pan <amadeus@jmu.edu.cn>
Date:   Mon Jan 22 21:02:19 2024 +0800

    net: ethernet: mtk_eth_soc: remove duplicate if statements
    
    It seems that there was something wrong with backport,
    causing `if (err)` to appear twice in the same place.
    
    Fixes: da86a63479e ("net: ethernet: mtk_eth_soc: fix error handling in mtk_open()")
    Cc: Liu Jian <liujian56@huawei.com>
    Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames [+ + +]
Author: Sanjuán García, Jorge <Jorge.SanjuanGarcia@duagon.com>
Date:   Fri Jan 5 08:55:43 2024 +0000

    net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames
    
    [ Upstream commit 64e47d8afb5ca533b27efc006405e5bcae2c4a7b ]
    
    The value of AM65_CPSW_MAX_PACKET_SIZE represents the maximum length
    of a received frame. This value is written to the register
    AM65_CPSW_PORT_REG_RX_MAXLEN.
    
    The maximum MTU configured on the network device should then leave
    some room for the ethernet headers and frame check. Otherwise, if
    the network interface is configured to its maximum mtu possible,
    the frames will be larger than AM65_CPSW_MAX_PACKET_SIZE and will
    get dropped as oversized.
    
    The switch supports ethernet frame sizes between 64 and 2024 bytes
    (including VLAN) as stated in the technical reference manual, so
    define AM65_CPSW_MAX_PACKET_SIZE with that maximum size.
    
    Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
    Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
    Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Link: https://lore.kernel.org/r/20240105085530.14070-2-jorge.sanjuangarcia@duagon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: netlabel: Fix kerneldoc warnings [+ + +]
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Wed Oct 28 01:53:50 2020 +0100

    net: netlabel: Fix kerneldoc warnings
    
    [ Upstream commit 294ea29113104487a905d0f81c00dfd64121b3d9 ]
    
    net/netlabel/netlabel_calipso.c:376: warning: Function parameter or member 'ops' not described in 'netlbl_calipso_ops_register'
    
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Link: https://lore.kernel.org/r/20201028005350.930299-1-andrew@lunn.ch
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: ec4e9d630a64 ("calipso: fix memory leak in netlbl_calipso_add_pass()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: micrel: populate .soft_reset for KSZ9131 [+ + +]
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Fri Jan 5 10:52:42 2024 +0200

    net: phy: micrel: populate .soft_reset for KSZ9131
    
    [ Upstream commit e398822c4751017fe401f57409488f5948d12fb5 ]
    
    The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
    is used with the ravb Ethernet driver. It has been discovered that when
    bringing the Ethernet interface down/up continuously, e.g., with the
    following sh script:
    
    $ while :; do ifconfig eth0 down; ifconfig eth0 up; done
    
    the link speed and duplex are wrong after interrupting the bring down/up
    operation even though the Ethernet interface is up. To recover from this
    state the following configuration sequence is necessary (executed
    manually):
    
    $ ifconfig eth0 down
    $ ifconfig eth0 up
    
    The behavior has been identified also on the Microchip SAMA7G5-EK board
    which runs the macb driver and uses the same PHY.
    
    The order of PHY-related operations in ravb_open() is as follows:
    ravb_open() ->
      ravb_phy_start() ->
        ravb_phy_init() ->
          of_phy_connect() ->
            phy_connect_direct() ->
              phy_attach_direct() ->
                phy_init_hw() ->
                  phydev->drv->soft_reset()
                  phydev->drv->config_init()
                  phydev->drv->config_intr()
                phy_resume()
                  kszphy_resume()
    
    The order of PHY-related operations in ravb_close is as follows:
    ravb_close() ->
      phy_stop() ->
        phy_suspend() ->
          kszphy_suspend() ->
            genphy_suspend()
              // set BMCR_PDOWN bit in MII_BMCR
    
    In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
    to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
    Thus, when opening the interface after it has been  previously closed (via
    ravb_close()), the phydev->drv->config_init() and
    phydev->drv->config_intr() reach the KSZ9131 PHY driver via the
    ksz9131_config_init() and kszphy_config_intr() functions.
    
    KSZ9131 specifies that the MII management interface remains operational
    during SPD (Software Power-Down), but (according to manual):
    - Only access to the standard registers (0 through 31) is supported.
    - Access to MMD address spaces other than MMD address space 1 is possible
      if the spd_clock_gate_override bit is set.
    - Access to MMD address space 1 is not possible.
    
    The spd_clock_gate_override bit is not used in the KSZ9131 driver.
    
    ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
    accessesing MMD registers other than those in address space 1.
    
    The datasheet for the KSZ9131 does not specify what happens if registers
    from an unsupported address space are accessed while the PHY is in SPD.
    
    To fix the issue the .soft_reset method has been instantiated for KSZ9131,
    too. This resets the PHY to the default state before doing any
    configurations to it, thus switching it out of SPD.
    
    Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qrtr: ns: Return 0 if server port is not present [+ + +]
Author: Sarannya S <quic_sarannya@quicinc.com>
Date:   Thu Dec 21 15:36:51 2023 +0530

    net: qrtr: ns: Return 0 if server port is not present
    
    [ Upstream commit 9bf2e9165f90dc9f416af53c902be7e33930f728 ]
    
    When a 'DEL_CLIENT' message is received from the remote, the corresponding
    server port gets deleted. A DEL_SERVER message is then announced for this
    server. As part of handling the subsequent DEL_SERVER message, the name-
    server attempts to delete the server port which results in a '-ENOENT' error.
    The return value from server_del() is then propagated back to qrtr_ns_worker,
    causing excessive error prints.
    To address this, return 0 from control_cmd_del_server() without checking the
    return value of server_del(), since the above scenario is not an error case
    and hence server_del() doesn't have any other error return value.
    
    Signed-off-by: Sarannya Sasikumar <quic_sarannya@quicinc.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: qualcomm: rmnet: fix global oob in rmnet_policy [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Wed Jan 10 14:14:00 2024 +0800

    net: qualcomm: rmnet: fix global oob in rmnet_policy
    
    [ Upstream commit b33fb5b801c6db408b774a68e7c8722796b59ecc ]
    
    The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
    global out-of-bounds read when parsing the netlink attributes. See bug
    trace below:
    
    ==================================================================
    BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
    BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
    Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
    
    CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:284 [inline]
     print_report+0x172/0x475 mm/kasan/report.c:395
     kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
     validate_nla lib/nlattr.c:386 [inline]
     __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
     __nla_parse+0x3e/0x50 lib/nlattr.c:697
     nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
     __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
     rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
     rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
     netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0x154/0x190 net/socket.c:734
     ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
     ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
     __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fdcf2072359
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
    RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
    RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
     </TASK>
    
    The buggy address belongs to the variable:
     rmnet_policy+0x30/0xe0
    
    The buggy address belongs to the physical page:
    page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
    flags: 0x200000000001000(reserved|node=0|zone=2)
    raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
    raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
     ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
    >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
                                                     ^
     ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
     ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
    
    According to the comment of `nla_parse_nested_deprecated`, the maxtype
    should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.
    
    Fixes: 14452ca3b5ce ("net: qualcomm: rmnet: Export mux_id and flags to netlink")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Reviewed-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20240110061400.3356108-1-linma@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ravb: Fix dma_addr_t truncation in error case [+ + +]
Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date:   Sat Jan 13 10:22:21 2024 +0600

    net: ravb: Fix dma_addr_t truncation in error case
    
    [ Upstream commit e327b2372bc0f18c30433ac40be07741b59231c5 ]
    
    In ravb_start_xmit(), ravb driver uses u32 variable to store result of
    dma_map_single() call. Since ravb hardware has 32-bit address fields in
    descriptors, this works properly when mapping is successful - it is
    platform's job to provide mapping addresses that fit into hardware
    limitations.
    
    However, in failure case dma_map_single() returns DMA_MAPPING_ERROR
    constant that is 64-bit when dma_addr_t is 64-bit. Storing this constant
    in u32 leads to truncation, and further call to dma_mapping_error()
    fails to notice the error.
    
    Fix that by storing result of dma_map_single() in a dma_addr_t
    variable.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: nf_tables: do not allow mismatch field size and set key length [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Jan 14 23:53:39 2024 +0100

    netfilter: nf_tables: do not allow mismatch field size and set key length
    
    [ Upstream commit 3ce67e3793f48c1b9635beb9bb71116ca1e51b58 ]
    
    The set description provides the size of each field in the set whose sum
    should not mismatch the set key length, bail out otherwise.
    
    I did not manage to crash nft_set_pipapo with mismatch fields and set key
    length so far, but this is UB which must be disallowed.
    
    Fixes: f3a2181e16f1 ("netfilter: nf_tables: Support for sets with multiple ranged fields")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: mark newset as dead on transaction abort [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Nov 27 11:00:37 2023 +0100

    netfilter: nf_tables: mark newset as dead on transaction abort
    
    [ Upstream commit 08e4c8c5919fd405a4d709b4ba43d836894a26eb ]
    
    If a transaction is aborted, we should mark the to-be-released NEWSET dead,
    just like commit path does for DEL and DESTROYSET commands.
    
    In both cases all remaining elements will be released via
    set->ops->destroy().
    
    The existing abort code does NOT post the actual release to the work queue.
    Also the entire __nf_tables_abort() function is wrapped in gc_seq
    begin/end pair.
    
    Therefore, async gc worker will never try to release the pending set
    elements, as gc sequence is always stale.
    
    It might be possible to speed up transaction aborts via work queue too,
    this would result in a race and a possible use-after-free.
    
    So fix this before it becomes an issue.
    
    Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jan 15 12:50:29 2024 +0100

    netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description
    
    [ Upstream commit 113661e07460a6604aacc8ae1b23695a89e7d4b3 ]
    
    It is still possible to set on the NFT_SET_CONCAT flag by specifying a
    set size and no field description, report EINVAL in such case.
    
    Fixes: 1b6345d4160e ("netfilter: nf_tables: check NFT_SET_CONCAT flag if field_count is specified")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: skip dead set elements in netlink dump [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jan 15 00:14:38 2024 +0100

    netfilter: nf_tables: skip dead set elements in netlink dump
    
    [ Upstream commit 6b1ca88e4bb63673dc9f9c7f23c899f22c3cb17a ]
    
    Delete from packet path relies on the garbage collector to purge
    elements with NFT_SET_ELEM_DEAD_BIT on.
    
    Skip these dead elements from nf_tables_dump_setelem() path, I very
    rarely see tests/shell/testcases/maps/typeof_maps_add_delete reports
    [DUMP FAILED] showing a mismatch in the expected output with an element
    that should not be there.
    
    If the netlink dump happens before GC worker run, it might show dead
    elements in the ruleset listing.
    
    nft_rhash_get() already skips dead elements in nft_rhash_cmp(),
    therefore, it already does not show the element when getting a single
    element via netlink control plane.
    
    Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netlabel: remove unused parameter in netlbl_netlink_auditinfo() [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed May 19 15:34:38 2021 +0800

    netlabel: remove unused parameter in netlbl_netlink_auditinfo()
    
    [ Upstream commit f7e0318a314f9271b0f0cdd4bfdc691976976d8c ]
    
    loginuid/sessionid/secid have been read from 'current' instead of struct
    netlink_skb_parms, the parameter 'skb' seems no longer needed.
    
    Fixes: c53fa1ed92cd ("netlink: kill loginuid/sessionid/sid members from struct netlink_skb_parms")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: ec4e9d630a64 ("calipso: fix memory leak in netlbl_calipso_add_pass()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Nov 15 13:55:29 2023 -0500

    NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT
    
    [ Upstream commit 037e56a22ff37f9a9c2330b66cff55d3d1ff9b90 ]
    
    Once the client has processed the CB_LAYOUTRECALL, but has not yet
    successfully returned the layout, the server is supposed to switch to
    returning NFS4ERR_RETURNCONFLICT. This patch ensures that we handle
    that return value correctly.
    
    Fixes: 183d9e7b112a ("pnfs: rework LAYOUTGET retry handling")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nouveau/tu102: flush all pdbs on vmm flush [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Nov 30 11:08:52 2023 +1000

    nouveau/tu102: flush all pdbs on vmm flush
    
    [ Upstream commit cb9c919364653eeafb49e7ff5cd32f1ad64063ac ]
    
    This is a hack around a bug exposed with the GSP code, I'm not sure
    what is happening exactly, but it appears some of our flushes don't
    result in proper tlb invalidation for out BAR2 and we get a BAR2
    fault from GSP and it all dies.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231130010852.4034774-1-airlied@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-core: check for too small lba shift [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue Nov 28 09:36:04 2023 -0800

    nvme-core: check for too small lba shift
    
    [ Upstream commit 74fbc88e161424b3b96a22b23a8e3e1edab9d05c ]
    
    The block layer doesn't support logical block sizes smaller than 512
    bytes. The nvme spec doesn't support that small either, but the driver
    isn't checking to make sure the device responded with usable data.
    Failing to catch this will result in a kernel bug, either from a
    division by zero when stacking, or a zero length bio.
    
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: introduce helper function to get ctrl state [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Mon Oct 30 08:13:09 2023 -0700

    nvme: introduce helper function to get ctrl state
    
    [ Upstream commit 5c687c287c46fadb14644091823298875a5216aa ]
    
    The controller state is typically written by another CPU, so reading it
    should ensure no optimizations are taken. This is a repeated pattern in
    the driver, so start with adding a convenience function that returns the
    controller state with READ_ONCE().
    
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-tcp: fix a crash in nvmet_req_complete() [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Fri Dec 22 16:17:49 2023 +0100

    nvmet-tcp: fix a crash in nvmet_req_complete()
    
    [ Upstream commit 0849a5441358cef02586fb2d60f707c0db195628 ]
    
    in nvmet_tcp_handle_h2c_data_pdu(), if the host sends a data_offset
    different from rbytes_done, the driver ends up calling nvmet_req_complete()
    passing a status error.
    The problem is that at this point cmd->req is not yet initialized,
    the kernel will crash after dereferencing a NULL pointer.
    
    Fix the bug by replacing the call to nvmet_req_complete() with
    nvmet_tcp_fatal_error().
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Reviewed-by: Keith Busch <kbsuch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Fri Dec 22 16:17:48 2023 +0100

    nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
    
    [ Upstream commit efa56305908ba20de2104f1b8508c6a7401833be ]
    
    If the host sends an H2CData command with an invalid DATAL,
    the kernel may crash in nvmet_tcp_build_pdu_iovec().
    
    Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000000
    lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]
    Call trace:
      process_one_work+0x174/0x3c8
      worker_thread+0x2d0/0x3e8
      kthread+0x104/0x110
    
    Fix the bug by raising a fatal error if DATAL isn't coherent
    with the packet size.
    Also, the PDU length should never exceed the MAXH2CDATA parameter which
    has been communicated to the host in nvmet_tcp_handle_icreq().
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-tcp: Fix the H2C expected PDU len calculation [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Fri Jan 5 09:14:44 2024 +0100

    nvmet-tcp: Fix the H2C expected PDU len calculation
    
    [ Upstream commit 9a1abc24850eb759e36a2f8869161c3b7254c904 ]
    
    The nvmet_tcp_handle_h2c_data_pdu() function should take into
    consideration the possibility that the header digest and/or the data
    digests are enabled when calculating the expected PDU length, before
    comparing it to the value stored in cmd->pdu_len.
    
    Fixes: efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: Add of_property_present() helper [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Thu Feb 9 15:35:01 2023 -0600

    of: Add of_property_present() helper
    
    [ Upstream commit 9cbad37ce8122de32a1529e394b468bc101c9e7f ]
    
    Add an of_property_present() function similar to
    fwnode_property_present(). of_property_read_bool() could be used
    directly, but it is cleaner to not use it on non-boolean properties.
    
    Reviewed-by: Frank Rowand <frowand.list@gmail.com>
    Tested-by: Frank Rowand <frowand.list@gmail.com>
    Link: https://lore.kernel.org/all/20230215215547.691573-1-robh@kernel.org/
    Signed-off-by: Rob Herring <robh@kernel.org>
    Stable-dep-of: c4a5118a3ae1 ("cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: Fix double free in of_parse_phandle_with_args_map [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Fri Dec 29 11:54:11 2023 +0100

    of: Fix double free in of_parse_phandle_with_args_map
    
    [ Upstream commit 4dde83569832f9377362e50f7748463340c5db6b ]
    
    In of_parse_phandle_with_args_map() the inner loop that
    iterates through the map entries calls of_node_put(new)
    to free the reference acquired by the previous iteration
    of the inner loop. This assumes that the value of "new" is
    NULL on the first iteration of the inner loop.
    
    Make sure that this is true in all iterations of the outer
    loop by setting "new" to NULL after its value is assigned to "cur".
    
    Extend the unittest to detect the double free and add an additional
    test case that actually triggers this path.
    
    Fixes: bd6f2fd5a1 ("of: Support parsing phandle argument lists through a nexus node")
    Cc: Stephen Boyd <stephen.boyd@linaro.org>
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Link: https://lore.kernel.org/r/20231229105411.1603434-1-lk@c--e.de
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: property: define of_property_read_u{8,16,32,64}_array() unconditionally [+ + +]
Author: Michael Walle <michael@walle.cc>
Date:   Tue Jan 18 18:35:03 2022 +0100

    of: property: define of_property_read_u{8,16,32,64}_array() unconditionally
    
    [ Upstream commit 2ca42c3ad9ed875b136065b010753a4caaaa1d38 ]
    
    We can get rid of all the empty stubs because all these functions call
    of_property_read_variable_u{8,16,32,64}_array() which already have an
    empty stub if CONFIG_OF is not defined.
    
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220118173504.2867523-3-michael@walle.cc
    Stable-dep-of: c4a5118a3ae1 ("cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

of: unittest: Fix of_count_phandle_with_args() expected value message [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Jan 11 09:50:25 2024 +0100

    of: unittest: Fix of_count_phandle_with_args() expected value message
    
    [ Upstream commit 716089b417cf98d01f0dc1b39f9c47e1d7b4c965 ]
    
    The expected result value for the call to of_count_phandle_with_args()
    was updated from 7 to 8, but the accompanying error message was
    forgotten.
    
    Fixes: 4dde83569832f937 ("of: Fix double free in of_parse_phandle_with_args_map")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20240111085025.2073894-1-geert+renesas@glider.be
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parport: parport_serial: Add Brainboxes BAR details [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Thu Nov 2 21:07:05 2023 +0000

    parport: parport_serial: Add Brainboxes BAR details
    
    commit 65fde134b0a4ffe838729f9ee11b459a2f6f2815 upstream.
    
    Add BAR/enum entries for Brainboxes serial/parallel cards.
    
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/r/AS4PR02MB79035155C2D5C3333AE6FA52C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parport: parport_serial: Add Brainboxes device IDs and geometry [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Thu Nov 2 21:07:06 2023 +0000

    parport: parport_serial: Add Brainboxes device IDs and geometry
    
    commit 6aa1fc5a8085bbc01687aa708dcf2dbe637a5ee3 upstream.
    
    Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475,
    IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry"
    for the cards.
    This patch requires part 1 of this series.
    
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: Add ACS quirk for more Zhaoxin Root Ports [+ + +]
Author: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
Date:   Mon Dec 11 17:15:43 2023 +0800

    PCI: Add ACS quirk for more Zhaoxin Root Ports
    
    commit e367e3c765f5477b2e79da0f1399aed49e2d1e37 upstream.
    
    Add more Root Port Device IDs to pci_quirk_zhaoxin_pcie_ports_acs() for
    some new Zhaoxin platforms.
    
    Fixes: 299bd044a6f3 ("PCI: Add ACS quirk for Zhaoxin Root/Downstream Ports")
    Link: https://lore.kernel.org/r/20231211091543.735903-1-LeoLiu-oc@zhaoxin.com
    Signed-off-by: LeoLiuoc <LeoLiu-oc@zhaoxin.com>
    [bhelgaas: update subject, drop changelog, add Fixes, add stable tag, fix
    whitespace, wrap code comment]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: <stable@vger.kernel.org>    # 5.7
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: keystone: Fix race condition when initializing PHYs [+ + +]
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Wed Sep 27 09:48:45 2023 +0530

    PCI: keystone: Fix race condition when initializing PHYs
    
    [ Upstream commit c12ca110c613a81cb0f0099019c839d078cd0f38 ]
    
    The PCI driver invokes the PHY APIs using the ks_pcie_enable_phy()
    function. The PHY in this case is the Serdes. It is possible that the
    PCI instance is configured for two lane operation across two different
    Serdes instances, using one lane of each Serdes.
    
    In such a configuration, if the reference clock for one Serdes is
    provided by the other Serdes, it results in a race condition. After the
    Serdes providing the reference clock is initialized by the PCI driver by
    invoking its PHY APIs, it is not guaranteed that this Serdes remains
    powered on long enough for the PHY APIs based initialization of the
    dependent Serdes. In such cases, the PLL of the dependent Serdes fails
    to lock due to the absence of the reference clock from the former Serdes
    which has been powered off by the PM Core.
    
    Fix this by obtaining reference to the PHYs before invoking the PHY
    initialization APIs and releasing reference after the initialization is
    complete.
    
    Link: https://lore.kernel.org/linux-pci/20230927041845.1222080-1-s-vadapalli@ti.com
    Fixes: 49229238ab47 ("PCI: keystone: Cleanup PHY handling")
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Acked-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf env: Avoid recursively taking env->bpf_progs.lock [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Wed Dec 6 17:46:55 2023 -0800

    perf env: Avoid recursively taking env->bpf_progs.lock
    
    [ Upstream commit 9c51f8788b5d4e9f46afbcf563255cfd355690b3 ]
    
    Add variants of perf_env__insert_bpf_prog_info(), perf_env__insert_btf()
    and perf_env__find_btf prefixed with __ to indicate the
    env->bpf_progs.lock is assumed held.
    
    Call these variants when the lock is held to avoid recursively taking it
    and potentially having a thread deadlock with itself.
    
    Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Acked-by: Song Liu <song@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Link: https://lore.kernel.org/r/20231207014655.1252484-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf genelf: Set ELF program header addresses properly [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Mon Dec 11 23:05:44 2023 -0800

    perf genelf: Set ELF program header addresses properly
    
    [ Upstream commit 1af478903fc48c1409a8dd6b698383b62387adf1 ]
    
    The text section starts after the ELF headers so PHDR.p_vaddr and
    others should have the correct addresses.
    
    Fixes: babd04386b1df8c3 ("perf jit: Include program header in ELF files")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Fangrui Song <maskray@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Lieven Hey <lieven.hey@kdab.com>
    Cc: Milian Wolff <milian.wolff@kdab.com>
    Cc: Pablo Galindo <pablogsal@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231212070547.612536-2-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: lochnagar: Don't build on MIPS [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Wed Nov 15 16:28:53 2023 +0000

    pinctrl: lochnagar: Don't build on MIPS
    
    [ Upstream commit 6588732445ff19f6183f0fa72ddedf67e5a5be32 ]
    
    MIPS appears to define a RST symbol at a high level, which clashes
    with some register naming in the driver. Since there is currently
    no case for running this driver on MIPS devices simply cut off the
    build of this driver on MIPS.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202311071303.JJMAOjy4-lkp@intel.com/
    Suggested-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20231115162853.1891940-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
power: supply: cw2015: correct time_to_empty units in sysfs [+ + +]
Author: Jan Palus <jpalus@fastmail.com>
Date:   Sat Nov 11 23:17:04 2023 +0100

    power: supply: cw2015: correct time_to_empty units in sysfs
    
    [ Upstream commit f37669119423ca852ca855b24732f25c0737aa57 ]
    
    RRT_ALRT register holds remaining battery time in minutes therefore it
    needs to be scaled accordingly when exposing TIME_TO_EMPTY via sysfs
    expressed in seconds
    
    Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver")
    Signed-off-by: Jan Palus <jpalus@fastmail.com>
    Link: https://lore.kernel.org/r/20231111221704.5579-1-jpalus@fastmail.com
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/44x: select I2C for CURRITUCK [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu Nov 30 21:51:59 2023 -0800

    powerpc/44x: select I2C for CURRITUCK
    
    [ Upstream commit 4a74197b65e69c46fe6e53f7df2f4d6ce9ffe012 ]
    
    Fix build errors when CURRITUCK=y and I2C is not builtin (=m or is
    not set). Fixes these build errors:
    
    powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `avr_halt_system':
    ppc476.c:(.text+0x58): undefined reference to `i2c_smbus_write_byte_data'
    powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `ppc47x_device_probe':
    ppc476.c:(.init.text+0x18): undefined reference to `i2c_register_driver'
    
    Fixes: 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: lore.kernel.org/r/202312010820.cmdwF5X9-lkp@intel.com
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231201055159.8371-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/imc-pmu: Add a null pointer check in update_events_in_group() [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Sun Nov 26 17:37:19 2023 +0800

    powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
    
    [ Upstream commit 0a233867a39078ebb0f575e2948593bbff5826b3 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231126093719.1440305-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powernv: Add a null pointer check in opal_event_init() [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Mon Nov 27 11:07:55 2023 +0800

    powerpc/powernv: Add a null pointer check in opal_event_init()
    
    [ Upstream commit 8649829a1dd25199bbf557b2621cedb4bf9b3050 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: 2717a33d6074 ("powerpc/opal-irqchip: Use interrupt names if present")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231127030755.1546750-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/powernv: Add a null pointer check in opal_powercap_init() [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Sun Nov 26 17:57:39 2023 +0800

    powerpc/powernv: Add a null pointer check in opal_powercap_init()
    
    [ Upstream commit e123015c0ba859cf48aa7f89c5016cc6e98e018d ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    
    Fixes: b9ef7b4b867f ("powerpc: Convert to using %pOFn instead of device_node.name")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231126095739.1501990-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/powernv: Add a null pointer check to scom_debug_init_one() [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Fri Dec 8 16:59:37 2023 +0800

    powerpc/powernv: Add a null pointer check to scom_debug_init_one()
    
    [ Upstream commit 9a260f2dd827bbc82cc60eb4f4d8c22707d80742 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure.
    Add a null pointer check, and release 'ent' to avoid memory leaks.
    
    Fixes: bfd2f0d49aef ("powerpc/powernv: Get rid of old scom_controller abstraction")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231208085937.107210-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries/memhotplug: Quieten some DLPAR operations [+ + +]
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Fri Dec 11 15:59:54 2020 +0100

    powerpc/pseries/memhotplug: Quieten some DLPAR operations
    
    [ Upstream commit 20e9de85edae3a5866f29b6cce87c9ec66d62a1b ]
    
    When attempting to remove by index a set of LMBs a lot of messages are
    displayed on the console, even when everything goes fine:
    
      pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000002d
      Offlined Pages 4096
      pseries-hotplug-mem: Memory at 2d0000000 was hot-removed
    
    The 2 messages prefixed by "pseries-hotplug-mem" are not really
    helpful for the end user, they should be debug outputs.
    
    In case of error, because some of the LMB's pages couldn't be
    offlined, the following is displayed on the console:
    
      pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000003e
      pseries-hotplug-mem: Failed to hot-remove memory at 3e0000000
      dlpar: Could not handle DLPAR request "memory remove index 0x8000003e"
    
    Again, the 2 messages prefixed by "pseries-hotplug-mem" are useless,
    and the generic DLPAR prefixed message should be enough.
    
    These 2 first changes are mainly triggered by the changes introduced
    in drmgr:
      https://groups.google.com/g/powerpc-utils-devel/c/Y6ef4NB3EzM/m/9cu5JHRxAQAJ
    
    Also, when adding a bunch of LMBs, a message is displayed in the console per LMB
    like these ones:
      pseries-hotplug-mem: Memory at 7e0000000 (drc index 8000007e) was hot-added
      pseries-hotplug-mem: Memory at 7f0000000 (drc index 8000007f) was hot-added
      pseries-hotplug-mem: Memory at 800000000 (drc index 80000080) was hot-added
      pseries-hotplug-mem: Memory at 810000000 (drc index 80000081) was hot-added
    
    When adding 1TB of memory and LMB size is 256MB, this leads to 4096
    messages to be displayed on the console. These messages are not really
    helpful for the end user, so moving them to the DEBUG level.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    [mpe: Tweak change log wording]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201211145954.90143-1-ldufour@linux.ibm.com
    Stable-dep-of: bd68ffce69f6 ("powerpc/pseries/memhp: Fix access beyond end of drmem array")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries/memhp: Fix access beyond end of drmem array [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Tue Nov 14 11:01:53 2023 -0600

    powerpc/pseries/memhp: Fix access beyond end of drmem array
    
    [ Upstream commit bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5 ]
    
    dlpar_memory_remove_by_index() may access beyond the bounds of the
    drmem lmb array when the LMB lookup fails to match an entry with the
    given DRC index. When the search fails, the cursor is left pointing to
    &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
    last valid entry in the array. The debug message at the end of the
    function then dereferences this pointer:
    
            pr_debug("Failed to hot-remove memory at %llx\n",
                     lmb->base_addr);
    
    This was found by inspection and confirmed with KASAN:
    
      pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
      Read of size 8 at addr c000000364e97fd0 by task bash/949
    
      dump_stack_lvl+0xa4/0xfc (unreliable)
      print_report+0x214/0x63c
      kasan_report+0x140/0x2e0
      __asan_load8+0xa8/0xe0
      dlpar_memory+0x298/0x1658
      handle_dlpar_errorlog+0x130/0x1d0
      dlpar_store+0x18c/0x3e0
      kobj_attr_store+0x68/0xa0
      sysfs_kf_write+0xc4/0x110
      kernfs_fop_write_iter+0x26c/0x390
      vfs_write+0x2d4/0x4e0
      ksys_write+0xac/0x1a0
      system_call_exception+0x268/0x530
      system_call_vectored_common+0x15c/0x2ec
    
      Allocated by task 1:
       kasan_save_stack+0x48/0x80
       kasan_set_track+0x34/0x50
       kasan_save_alloc_info+0x34/0x50
       __kasan_kmalloc+0xd0/0x120
       __kmalloc+0x8c/0x320
       kmalloc_array.constprop.0+0x48/0x5c
       drmem_init+0x2a0/0x41c
       do_one_initcall+0xe0/0x5c0
       kernel_init_freeable+0x4ec/0x5a0
       kernel_init+0x30/0x1e0
       ret_from_kernel_user_thread+0x14/0x1c
    
      The buggy address belongs to the object at c000000364e80000
       which belongs to the cache kmalloc-128k of size 131072
      The buggy address is located 0 bytes to the right of
       allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
    
      ==================================================================
      pseries-hotplug-mem: Failed to hot-remove memory at 0
    
    Log failed lookups with a separate message and dereference the
    cursor only when it points to a valid entry.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: 51925fb3c5c9 ("powerpc/pseries: Implement memory hotplug remove in the kernel")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231114-pseries-memhp-fixes-v1-1-fb8f2bb7c557@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: add crtsavres.o to always-y instead of extra-y [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Nov 21 08:23:32 2023 +0900

    powerpc: add crtsavres.o to always-y instead of extra-y
    
    [ Upstream commit 1b1e38002648819c04773647d5242990e2824264 ]
    
    crtsavres.o is linked to modules. However, as explained in commit
    d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
    and always-y"), 'make modules' does not build extra-y.
    
    For example, the following command fails:
    
      $ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig modules
        [snip]
        LD [M]  arch/powerpc/platforms/cell/spufs/spufs.ko
      ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory
      make[3]: *** [scripts/Makefile.modfinal:56: arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
      make[2]: *** [Makefile:1844: modules] Error 2
      make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350: __build_one_by_one] Error 2
      make: *** [Makefile:234: __sub-make] Error 2
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Fixes: baa25b571a16 ("powerpc/64: Do not link crtsavres.o in vmlinux")
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231120232332.4100288-1-masahiroy@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc: Remove in_kernel_text() [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Sun Jun 27 17:09:18 2021 +0000

    powerpc: Remove in_kernel_text()
    
    [ Upstream commit 09ca497528dac12cbbceab8197011c875a96d053 ]
    
    Last user of in_kernel_text() stopped using in with
    commit 549e8152de80 ("powerpc: Make the 64-bit kernel as a
    position-independent executable").
    
    Generic function is_kernel_text() does the same.
    
    So remote it.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/2a3a5b6f8cc0ef4e854d7b764f66aa8d2ee270d2.1624813698.git.christophe.leroy@csgroup.eu
    Stable-dep-of: 1b1e38002648 ("powerpc: add crtsavres.o to always-y instead of extra-y")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc() [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sun Nov 5 23:29:36 2023 +0300

    pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
    
    [ Upstream commit 86222a8fc16ec517de8da2604d904c9df3a08e5d ]
    
    In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
    64-bit value since persistent_ram_zone::buffer_size has type size_t which
    is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
    this value gets assigned to has (always 32-bit) *int* type.  Even if that
    value fits into *int* type, an overflow is still possible when calculating
    the size_t typed ecc_total variable further below since there's no cast to
    any 64-bit type before multiplication.  Declaring the ecc_blocks variable
    as *size_t* should fix this mess...
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE static
    analysis tool.
    
    Fixes: 9cc05ad97c57 ("staging: android: persistent_ram: refactor ecc support")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20231105202936.25694-1-s.shtylyov@omp.ru
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: jz4740: Don't use dev_err_probe() in .request() [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sat Jan 6 15:13:03 2024 +0100

    pwm: jz4740: Don't use dev_err_probe() in .request()
    
    commit 9320fc509b87b4d795fb37112931e2f4f8b5c55f upstream.
    
    dev_err_probe() is only supposed to be used in probe functions. While it
    probably doesn't hurt, both the EPROBE_DEFER handling and calling
    device_set_deferred_probe_reason() are conceptually wrong in the request
    callback. So replace the call by dev_err() and a separate return
    statement.
    
    This effectively reverts commit c0bfe9606e03 ("pwm: jz4740: Simplify
    with dev_err_probe()").
    
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240106141302.1253365-2-u.kleine-koenig@pengutronix.de
    Fixes: c0bfe9606e03 ("pwm: jz4740: Simplify with dev_err_probe()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pwm: stm32: Fix enable count for clk in .probe() [+ + +]
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Thu Oct 19 22:07:04 2023 +0200

    pwm: stm32: Fix enable count for clk in .probe()
    
    [ Upstream commit 19f1016ea9600ed89bc24247c36ff5934ad94fbb ]
    
    Make the driver take over hardware state without disabling in .probe()
    and enable the clock for each enabled channel.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    [ukleinek: split off from a patch that also implemented .get_state()]
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
    Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: stm32: Use hweight32 in stm32_pwm_detect_channels [+ + +]
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Thu Oct 19 22:07:02 2023 +0200

    pwm: stm32: Use hweight32 in stm32_pwm_detect_channels
    
    [ Upstream commit 41fa8f57c0d269243fe3bde2bce71e82c884b9ad ]
    
    Use hweight32() to count the CCxE bits in stm32_pwm_detect_channels().
    Since the return value is assigned to chip.npwm, change it to unsigned
    int as well.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Stable-dep-of: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: stm32: Use regmap_clear_bits and regmap_set_bits where applicable [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Dec 2 19:35:18 2022 +0100

    pwm: stm32: Use regmap_clear_bits and regmap_set_bits where applicable
    
    [ Upstream commit 632ae5d7eb348b3ef88552ec0999260b6f9d6ab1 ]
    
    Found using coccinelle and the following semantic patch:
    
    @@
    expression map, reg, bits;
    @@
    
    - regmap_update_bits(map, reg, bits, bits)
    + regmap_set_bits(map, reg, bits)
    
    @@
    expression map, reg, bits;
    @@
    
    - regmap_update_bits(map, reg, bits, 0)
    + regmap_clear_bits(map, reg, bits)
    
    Tested-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20221115111347.3705732-6-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Stable-dep-of: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcu: Create an unrcu_pointer() to remove __rcu from a pointer [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu Jun 24 18:05:51 2021 +0200

    rcu: Create an unrcu_pointer() to remove __rcu from a pointer
    
    [ Upstream commit 76c8eaafe4f061f3790112842a2fbb297e4bea88 ]
    
    The xchg() and cmpxchg() functions are sometimes used to carry out RCU
    updates.  Unfortunately, this can result in sparse warnings for both
    the old-value and new-value arguments, as well as for the return value.
    The arguments can be dealt with using RCU_INITIALIZER():
    
            old_p = xchg(&p, RCU_INITIALIZER(new_p));
    
    But a sparse warning still remains due to assigning the __rcu pointer
    returned from xchg to the (most likely) non-__rcu pointer old_p.
    
    This commit therefore provides an unrcu_pointer() macro that strips
    the __rcu.  This macro can be used as follows:
    
            old_p = unrcu_pointer(xchg(&p, RCU_INITIALIZER(new_p)));
    
    Reported-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Stable-dep-of: 5f35a624c1e3 ("drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/usnic: Silence uninitialized symbol smatch warnings [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Mon Nov 13 11:28:02 2023 +0200

    RDMA/usnic: Silence uninitialized symbol smatch warnings
    
    [ Upstream commit b9a85e5eec126d6ae6c362f94b447c223e8fe6e4 ]
    
    The patch 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16, 2005
    (linux-next), leads to the following Smatch static checker warning:
    
            drivers/infiniband/hw/mthca/mthca_cmd.c:644 mthca_SYS_EN()
            error: uninitialized symbol 'out'.
    
    drivers/infiniband/hw/mthca/mthca_cmd.c
        636 int mthca_SYS_EN(struct mthca_dev *dev)
        637 {
        638         u64 out;
        639         int ret;
        640
        641         ret = mthca_cmd_imm(dev, 0, &out, 0, 0, CMD_SYS_EN, CMD_TIME_CLASS_D);
    
    We pass out here and it gets used without being initialized.
    
            err = mthca_cmd_post(dev, in_param,
                                 out_param ? *out_param : 0,
                                             ^^^^^^^^^^
                                 in_modifier, op_modifier,
                                 op, context->token, 1);
    
    It's the same in mthca_cmd_wait() and mthca_cmd_poll().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/533bc3df-8078-4397-b93d-d1f6cec9b636@moroto.mountain
    Link: https://lore.kernel.org/r/c559cb7113158c02d75401ac162652072ef1b5f0.1699867650.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Aug 10 11:13:00 2023 +0200

    reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning
    
    [ Upstream commit b5ec294472794ed9ecba0cb4b8208372842e7e0d ]
    
    'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
    causes:
    
      hi6220_reset.c:166:9: error: cast to smaller integer type 'enum hi6220_reset_ctrl_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230810091300.70197-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 18 11:14:14 2024 +0100

    Revert "ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek"
    
    This reverts commit 608fc58858bfa7552a9824c2f0e4a3ab8dd4efaa which is
    commit c775cbf62ed4911e4f0f23880f01815753123690 upstream.
    
    It is reported to cause problems, so drop it from the 5.10.y tree for now.
    
    Link: https://lore.kernel.org/r/845b3053-d47b-4717-9665-79b120da133b@sirena.org.uk
    Reported-by: Mark Brown <broonie@kernel.org>
    Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "gfs2: Don't reject a supposedly full bitmap if we have blocks reserved" [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Tue Oct 6 14:29:04 2020 +0200

    Revert "gfs2: Don't reject a supposedly full bitmap if we have blocks reserved"
    
    [ Upstream commit 2fdc2fa21bc72ec06c0c9f0e30b88fe1f2486b75 ]
    
    This reverts commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4.
    
    It turns out that we're only setting the GBF_FULL flag of a bitmap if we've
    been scanning from the beginning of the bitmap until the end and we haven't
    found a single free block, and we're not skipping reservations in that process,
    either.  This means that in gfs2_rbm_find, we can always skip bitmaps with the
    GBF_FULL flag set.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: 8877243beafa ("gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only" [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Fri Dec 22 22:11:33 2023 +0000

    Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only"
    
    commit afe28cd686aeb77e8d9140d50fb1cf06a7ecb731 upstream.
    
    This reverts commit e835c0a4e23c38531dcee5ef77e8d1cf462658c7.
    
    Don't omit soft-reset. During initialization, the driver may need to
    perform a soft reset to ensure the phy is ready when the controller
    updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset.
    Many platforms often have access to DCTL register for soft-reset despite
    being host-only. If there are actual reported issues from the platforms
    that don't expose DCTL registers, then we will need to revisit (perhaps
    to teach dwc3 to perform xhci's soft-reset USBCMD.HCRST).
    
    Cc:  <stable@vger.kernel.org>
    Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/7668ab11a48f260820825274976eb41fec7f54d1.1703282469.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: dwc3: Soft reset phy on probe for host" [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Fri Dec 22 22:11:27 2023 +0000

    Revert "usb: dwc3: Soft reset phy on probe for host"
    
    commit 7059fbebcb00554c3f31e5b5d93ef6d2d96dc7b4 upstream.
    
    This reverts commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b.
    
    The phy soft reset GUSB2PHYCFG.PHYSOFTRST only applies to UTMI phy, not
    ULPI. This fix is incomplete.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 8bea147dfdf8 ("usb: dwc3: Soft reset phy on probe for host")
    Reported-by: Köry Maincent <kory.maincent@bootlin.com>
    Closes: https://lore.kernel.org/linux-usb/20231205151959.5236c231@kmaincent-XPS-13-7390
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/29a26593a60eba727de872a3e580a674807b3339.1703282469.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs" [+ + +]
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue Jan 2 11:11:41 2024 +0200

    Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs"
    
    commit 9c6b789e954fae73c548f39332bcc56bdf0d4373 upstream.
    
    This reverts commit b17b7fe6dd5c6ff74b38b0758ca799cdbb79e26e.
    
    That commit messed up the reference counting, so it needs to
    be rethought.
    
    Fixes: b17b7fe6dd5c ("usb: typec: class: fix typec_altmode_put_partner to put plugs")
    Cc:  <stable@vger.kernel.org>
    Cc: RD Babiera <rdbabiera@google.com>
    Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com>
    Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240102091142.2136472-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Dec 13 17:54:03 2023 -0500

    ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI
    
    [ Upstream commit 712292308af2265cd9b126aedfa987f10f452a33 ]
    
    As the ring buffer recording requires cmpxchg() to work, if the
    architecture does not support cmpxchg in NMI, then do not do any recording
    within an NMI.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231213175403.6fc18540@gandalf.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rootfs: Fix support for rootfstype= when root= is given [+ + +]
Author: Stefan Berger <stefanb@linux.ibm.com>
Date:   Sun Nov 19 20:12:48 2023 -0500

    rootfs: Fix support for rootfstype= when root= is given
    
    commit 21528c69a0d8483f7c6345b1a0bc8d8975e9a172 upstream.
    
    Documentation/filesystems/ramfs-rootfs-initramfs.rst states:
    
      If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
      default.  To force ramfs, add "rootfstype=ramfs" to the kernel command
      line.
    
    This currently does not work when root= is provided since then
    saved_root_name contains a string and rootfstype= is ignored. Therefore,
    ramfs is currently always chosen when root= is provided.
    
    The current behavior for rootfs's filesystem is:
    
       root=       | rootfstype= | chosen rootfs filesystem
       ------------+-------------+--------------------------
       unspecified | unspecified | tmpfs
       unspecified | tmpfs       | tmpfs
       unspecified | ramfs       | ramfs
        provided   | ignored     | ramfs
    
    rootfstype= should be respected regardless whether root= is given,
    as shown below:
    
       root=       | rootfstype= | chosen rootfs filesystem
       ------------+-------------+--------------------------
       unspecified | unspecified | tmpfs  (as before)
       unspecified | tmpfs       | tmpfs  (as before)
       unspecified | ramfs       | ramfs  (as before)
        provided   | unspecified | ramfs  (compatibility with before)
        provided   | tmpfs       | tmpfs  (new)
        provided   | ramfs       | ramfs  (new)
    
    This table represents the new behavior.
    
    Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Rob Landley <rob@landley.net>
    Link: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/
    Reviewed-and-Tested-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
    Link: https://lore.kernel.org/r/20231120011248.396012-1-stefanb@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rtlwifi: rtl8192de: make arrays static const, makes object smaller [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Tue Aug 3 15:49:48 2021 +0100

    rtlwifi: rtl8192de: make arrays static const, makes object smaller
    
    [ Upstream commit b05897ca8c821a16ac03850c4704fe460b3f21a0 ]
    
    Don't populate arrays the stack but instead make them static const. Replace
    array channel_info with channel_all since it contains the same data as
    channel_all. Makes object code smaller by 961 bytes.
    
    Before:
       text    data     bss     dec    hex  filename
     128147   44250    1024  173421  2a56d  ../realtek/rtlwifi/rtl8192de/phy.o
    
    After
       text    data     bss     dec    hex  filename
     127122   44314    1024  172460  2a1ac  ../realtek/rtlwifi/rtl8192de/phy.o
    
    (gcc version 10.2.0)
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210803144949.79433-2-colin.king@canonical.com
    Stable-dep-of: b8b2baad2e65 ("wifi: rtlwifi: rtl8192de: using calculate_bit_shift()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/pci: fix max size calculation in zpci_memcpy_toio() [+ + +]
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Nov 28 16:22:49 2023 +0100

    s390/pci: fix max size calculation in zpci_memcpy_toio()
    
    [ Upstream commit 80df7d6af7f6d229b34cf237b2cc9024c07111cd ]
    
    The zpci_get_max_write_size() helper is used to determine the maximum
    size a PCI store or load can use at a given __iomem address.
    
    For the PCI block store the following restrictions apply:
    
    1. The dst + len must not cross a 4K boundary in the (pseudo-)MMIO space
    2. len must not exceed ZPCI_MAX_WRITE_SIZE
    3. len must be a multiple of 8 bytes
    4. The src address must be double word (8 byte) aligned
    5. The dst address must be double word (8 byte) aligned
    
    Otherwise only a normal PCI store which takes its src value from
    a register can be used. For these PCI store restriction 1 still applies.
    Similarly 1 also applies to PCI loads.
    
    It turns out zpci_max_write_size() instead implements stricter
    conditions which prevents PCI block stores from being used where they
    can and should be used. In particular instead of conditions 4 and 5 it
    wrongly enforces both dst and src to be size aligned. This indirectly
    covers condition 1 but also prevents many legal PCI block stores.
    
    On top of the functional shortcomings the zpci_get_max_write_size() is
    misnamed as it is used for both read and write size calculations. Rename
    it to zpci_get_max_io_size() and implement the listed conditions
    explicitly.
    
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Fixes: cd24834130ac ("s390/pci: base support")
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    [agordeev@linux.ibm.com replaced spaces with tabs]
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/scm: fix virtual vs physical address confusion [+ + +]
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Thu Nov 23 22:52:53 2023 +0100

    s390/scm: fix virtual vs physical address confusion
    
    [ Upstream commit b1a6a1a77f0666a5a6dc0893ab6ec8fcae46f24c ]
    
    Fix virtual vs physical address confusion (which currently are the same).
    
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: fnic: Return error if vmalloc() failed [+ + +]
Author: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Date:   Tue Nov 28 14:10:08 2023 +0300

    scsi: fnic: Return error if vmalloc() failed
    
    [ Upstream commit f5f27a332a14f43463aa0075efa3a0c662c0f4a8 ]
    
    In fnic_init_module() exists redundant check for return value from
    fnic_debugfs_init(), because at moment it only can return zero. It make
    sense to process theoretical vmalloc() failure.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9730ddfb123d ("scsi: fnic: remove redundant assignment of variable rc")
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Link: https://lore.kernel.org/r/20231128111008.2280507-1-artem.chernyshev@red-soft.ru
    Reviewed-by: Karan Tilak Kumar <kartilak@cisco.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hisi_sas: Replace with standard error code return value [+ + +]
Author: Yihang Li <liyihang9@huawei.com>
Date:   Thu Dec 14 11:45:13 2023 +0800

    scsi: hisi_sas: Replace with standard error code return value
    
    [ Upstream commit d34ee535705eb43885bc0f561c63046f697355ad ]
    
    In function hisi_sas_controller_prereset(), -ENOSYS (Function not
    implemented) should be returned if the driver does not support .soft_reset.
    Returns -EPERM (Operation not permitted) if HISI_SAS_RESETTING_BIT is
    already be set.
    
    In function _suspend_v3_hw(), returns -EPERM (Operation not permitted) if
    HISI_SAS_RESETTING_BIT is already be set.
    
    Fixes: 4522204ab218 ("scsi: hisi_sas: tidy host controller reset function a bit")
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1702525516-51258-3-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/net: fix grep checking for fib_nexthop_multiprefix [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Wed Dec 13 14:08:49 2023 +0800

    selftests/net: fix grep checking for fib_nexthop_multiprefix
    
    [ Upstream commit a33e9da3470499e9ff476138f271fb52d6bfe767 ]
    
    When running fib_nexthop_multiprefix test I saw all IPv6 test failed.
    e.g.
    
     ]# ./fib_nexthop_multiprefix.sh
     TEST: IPv4: host 0 to host 1, mtu 1300                              [ OK ]
     TEST: IPv6: host 0 to host 1, mtu 1300                              [FAIL]
    
     With -v it shows
    
     COMMAND: ip netns exec h0 /usr/sbin/ping6 -s 1350 -c5 -w5 2001:db8:101::1
     PING 2001:db8:101::1(2001:db8:101::1) 1350 data bytes
     From 2001:db8:100::64 icmp_seq=1 Packet too big: mtu=1300
    
     --- 2001:db8:101::1 ping statistics ---
     1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
    
     Route get
     2001:db8:101::1 via 2001:db8:100::64 dev eth0 src 2001:db8:100::1 metric 1024 expires 599sec mtu 1300 pref medium
     Searching for:
         2001:db8:101::1 from :: via 2001:db8:100::64 dev eth0 src 2001:db8:100::1 .* mtu 1300
    
    The reason is when CONFIG_IPV6_SUBTREES is not enabled, rt6_fill_node() will
    not put RTA_SRC info. After fix:
    
    ]# ./fib_nexthop_multiprefix.sh
    TEST: IPv4: host 0 to host 1, mtu 1300                              [ OK ]
    TEST: IPv6: host 0 to host 1, mtu 1300                              [ OK ]
    
    Fixes: 735ab2f65dce ("selftests: Add test with multiple prefixes using single nexthop")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://lore.kernel.org/r/20231213060856.4030084-7-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/powerpc: Fix error handling in FPU/VMX preemption tests [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Nov 29 00:27:44 2023 +1100

    selftests/powerpc: Fix error handling in FPU/VMX preemption tests
    
    [ Upstream commit 9dbd5927408c4a0707de73ae9dd9306b184e8fee ]
    
    The FPU & VMX preemption tests do not check for errors returned by the
    low-level asm routines, preempt_fpu() / preempt_vsx() respectively.
    That means any register corruption detected by the asm routines does not
    result in a test failure.
    
    Fix it by returning the return value of the asm routines from the
    pthread child routines.
    
    Fixes: e5ab8be68e44 ("selftests/powerpc: Test preservation of FPU and VMX regs across preemption")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231128132748.1990179-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes [+ + +]
Author: Amit Cohen <amcohen@nvidia.com>
Date:   Wed Jan 17 16:04:21 2024 +0100

    selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes
    
    [ Upstream commit b34f4de6d30cbaa8fed905a5080b6eace8c84dc7 ]
    
    'qos_pfc' test checks PFC behavior. The idea is to limit the traffic
    using a shaper somewhere in the flow of the packets. In this area, the
    buffer is smaller than the buffer at the beginning of the flow, so it fills
    up until there is no more space left. The test configures there PFC
    which is supposed to notice that the headroom is filling up and send PFC
    Xoff to indicate the transmitter to stop sending traffic for the priorities
    sharing this PG.
    
    The Xon/Xoff threshold is auto-configured and always equal to
    2*(MTU rounded up to cell size). Even after sending the PFC Xoff packet,
    traffic will keep arriving until the transmitter receives and processes
    the PFC packet. This amount of traffic is known as the PFC delay allowance.
    
    Currently the buffer for the delay traffic is configured as 100KB. The
    MTU in the test is 10KB, therefore the threshold for Xoff is about 20KB.
    This allows 80KB extra to be stored in this buffer.
    
    8-lane ports use two buffers among which the configured buffer is split,
    the Xoff threshold then applies to each buffer in parallel.
    
    The test does not take into account the behavior of 8-lane ports, when the
    ports are configured to 400Gbps with 8 lanes or 800Gbps with 8 lanes,
    packets are dropped and the test fails.
    
    Check if the relevant ports use 8 lanes, in such case double the size of
    the buffer, as the headroom is split half-half.
    
    Cc: Shuah Khan <shuah@kernel.org>
    Fixes: bfa804784e32 ("selftests: mlxsw: Add a PFC test")
    Signed-off-by: Amit Cohen <amcohen@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/23ff11b7dff031eb04a41c0f5254a2b636cd8ebb.1705502064.git.petrm@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mlxsw: qos_pfc: Convert to iproute2 dcb [+ + +]
Author: Petr Machata <petrm@nvidia.com>
Date:   Mon May 17 20:03:54 2021 +0300

    selftests: mlxsw: qos_pfc: Convert to iproute2 dcb
    
    [ Upstream commit b0bab2298ec9b3a837f8ef4a0cae4b42a4d03365 ]
    
    There is a dedicated tool for configuration of DCB in iproute2 now. Use it
    in the selftest instead of mlnx_qos.
    
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: b34f4de6d30c ("selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selinux: Fix error priority for bind with AF_UNSPEC on PF_INET6 socket [+ + +]
Author: Mickaël Salaün <mic@digikod.net>
Date:   Wed Jan 3 17:34:15 2024 +0100

    selinux: Fix error priority for bind with AF_UNSPEC on PF_INET6 socket
    
    [ Upstream commit bbf5a1d0e5d0fb3bdf90205aa872636122692a50 ]
    
    The IPv6 network stack first checks the sockaddr length (-EINVAL error)
    before checking the family (-EAFNOSUPPORT error).
    
    This was discovered thanks to commit a549d055a22e ("selftests/landlock:
    Add network tests").
    
    Cc: Eric Paris <eparis@parisplace.org>
    Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Cc: Paul Moore <paul@paul-moore.com>
    Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
    Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Closes: https://lore.kernel.org/r/0584f91c-537c-4188-9e4f-04f192565667@collabora.com
    Fixes: 0f8db8cc73df ("selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()")
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Nov 10 16:29:29 2023 +0100

    serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
    
    [ Upstream commit ad90d0358bd3b4554f243a425168fc7cebe7d04e ]
    
    Returning an error code from .remove() makes the driver core emit the
    little helpful error message:
    
            remove callback returned a non-zero value. This will be ignored.
    
    and then remove the device anyhow. So all resources that were not freed
    are leaked in this case. Skipping serial8250_unregister_port() has the
    potential to keep enough of the UART around to trigger a use-after-free.
    
    So replace the error return (and with it the little helpful error
    message) by a more useful error message and continue to cleanup.
    
    Fixes: e3f0c638f428 ("serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20231110152927.70601-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: imx: Correct clock error message in function probe() [+ + +]
Author: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Date:   Sun Dec 24 10:32:09 2023 +0100

    serial: imx: Correct clock error message in function probe()
    
    [ Upstream commit 3e189470cad27d41a3a9dc02649f965b7ed1c90f ]
    
    Correct the clock error message by changing the clock name.
    
    Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails")
    Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20231224093209.2612-1-cniedermaier@dh-electronics.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock [+ + +]
Author: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Date:   Tue Dec 26 12:36:47 2023 +0100

    serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock
    
    commit 7c45eaa813476bd195ac1227a64b52f9cf2e2030 upstream.
    
    There are register accesses in the function imx_uart_rs485_config(). The
    clock must be enabled for these accesses. This was ensured by calling it
    via the function uart_rs485_config() in the probe() function within the
    range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
    Deassert Transmit Enable on probe in driver-specific way") it was removed
    from the probe() function and is now only called through the function
    uart_add_one_port() which is located at the end of the probe() function.
    But the clock is already switched off in this area. To ensure that the
    clock is enabled during register access, move the disabling of the clock
    to the very end of the probe() function. To avoid leaking enabled clocks
    on error also add an error path for exiting with disabling the clock.
    
    Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Reviewed-by: Lukas Wunner <lukas@wunner.de>
    Link: https://lore.kernel.org/r/20231226113647.39376-1-cniedermaier@dh-electronics.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: imx: fix tx statemachine deadlock [+ + +]
Author: Paul Geurts <paul_geurts@live.nl>
Date:   Fri Nov 24 14:11:10 2023 +0100

    serial: imx: fix tx statemachine deadlock
    
    [ Upstream commit 78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0 ]
    
    When using the serial port as RS485 port, the tx statemachine is used to
    control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
    TTY port is closed in the middle of a transmission (for instance during
    userland application crash), imx_uart_shutdown disables the interface
    and disables the Transmission Complete interrupt. afer that,
    imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
    by the TC interrupt. This interrupt is disabled and therefore the tx
    statemachine never transitions out of SEND. The statemachine is in
    deadlock now, and the TX_EN remains low, making the interface useless.
    
    imx_uart_stop_tx now checks for incomplete transmission AND whether TC
    interrupts are enabled before bailing to be retriggered. This makes sure
    the state machine handling is reached, and is properly set to
    WAIT_AFTER_SEND.
    
    Fixes: cb1a60923609 ("serial: imx: implement rts delaying for rs485")
    Signed-off-by: Paul Geurts <paul_geurts@live.nl>
    Tested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Tested-by: Eberhard Stoll <eberhard.stoll@gmx.de>
    Link: https://lore.kernel.org/r/AM0PR09MB26758F651BC1B742EB45775995B8A@AM0PR09MB2675.eurprd09.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
software node: Let args be NULL in software_node_get_reference_args [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Thu Nov 9 12:10:09 2023 +0200

    software node: Let args be NULL in software_node_get_reference_args
    
    [ Upstream commit 1eaea4b3604eb9ca7d9a1e73d88fc121bb4061f5 ]
    
    fwnode_get_property_reference_args() may not be called with args argument
    NULL and while OF already supports this. Add the missing NULL check.
    
    The purpose is to be able to count the references.
    
    Fixes: b06184acf751 ("software node: Add software_node_get_reference_args()")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20231109101010.1329587-3-sakari.ailus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: sh-msiof: Enforce fixed DTDL for R-Car H3 [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Dec 12 09:12:38 2023 +0100

    spi: sh-msiof: Enforce fixed DTDL for R-Car H3
    
    [ Upstream commit e5c7bcb499840551cfbe85c6df177ebc50432bf0 ]
    
    Documentation says only DTDL of 200 is allowed for this SoC.
    
    Fixes: 4286db8456f4 ("spi: sh-msiof: Add R-Car Gen 2 and 3 fallback bindings")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://msgid.link/r/20231212081239.14254-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: spi-zynqmp-gqspi: fix driver kconfig dependencies [+ + +]
Author: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Date:   Mon Nov 6 20:23:55 2023 +0530

    spi: spi-zynqmp-gqspi: fix driver kconfig dependencies
    
    [ Upstream commit 424a8166764e462258fdccaaefbdeb07517c8b21 ]
    
    ZynqMP GQSPI driver no longer uses spi-master framework. It had been
    converted to use spi-mem framework. So remove driver dependency from
    spi-master and replace it with spi-mem.
    
    Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
    Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/1699282435-884917-1-git-send-email-radhey.shyam.pandey@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jan 15 17:35:55 2024 +0100

    tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug
    
    commit 71fee48fb772ac4f6cfa63dbebc5629de8b4cc09 upstream.
    
    When offlining and onlining CPUs the overall reported idle and iowait
    times as reported by /proc/stat jump backward and forward:
    
    cpu  132 0 176 225249 47 6 6 21 0 0
    cpu0 80 0 115 112575 33 3 4 18 0 0
    cpu1 52 0 60 112673 13 3 1 2 0 0
    
    cpu  133 0 177 226681 47 6 6 21 0 0
    cpu0 80 0 116 113387 33 3 4 18 0 0
    
    cpu  133 0 178 114431 33 6 6 21 0 0 <---- jump backward
    cpu0 80 0 116 114247 33 3 4 18 0 0
    cpu1 52 0 61 183 0 3 1 2 0 0        <---- idle + iowait start with 0
    
    cpu  133 0 178 228956 47 6 6 21 0 0 <---- jump forward
    cpu0 81 0 117 114929 33 3 4 18 0 0
    
    Reason for this is that get_idle_time() in fs/proc/stat.c has different
    sources for both values depending on if a CPU is online or offline:
    
    - if a CPU is online the values may be taken from its per cpu
      tick_cpu_sched structure
    
    - if a CPU is offline the values are taken from its per cpu cpustat
      structure
    
    The problem is that the per cpu tick_cpu_sched structure is set to zero on
    CPU offline. See tick_cancel_sched_timer() in kernel/time/tick-sched.c.
    
    Therefore when a CPU is brought offline and online afterwards both its idle
    and iowait sleeptime will be zero, causing a jump backward in total system
    idle and iowait sleeptime. In a similar way if a CPU is then brought
    offline again the total idle and iowait sleeptimes will jump forward.
    
    It looks like this behavior was introduced with commit 4b0c0f294f60
    ("tick: Cleanup NOHZ per cpu data on cpu down").
    
    This was only noticed now on s390, since we switched to generic idle time
    reporting with commit be76ea614460 ("s390/idle: remove arch_cpu_idle_time()
    and corresponding code").
    
    Fix this by preserving the values of idle_sleeptime and iowait_sleeptime
    members of the per-cpu tick_sched structure on CPU hotplug.
    
    Fixes: 4b0c0f294f60 ("tick: Cleanup NOHZ per cpu data on cpu down")
    Reported-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Link: https://lore.kernel.org/r/20240115163555.1004144-1-hca@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Add size check when printing trace_marker output [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Dec 12 08:44:44 2023 -0500

    tracing: Add size check when printing trace_marker output
    
    [ Upstream commit 60be76eeabb3d83858cc6577fc65c7d0f36ffd42 ]
    
    If for some reason the trace_marker write does not have a nul byte for the
    string, it will overflow the print:
    
      trace_seq_printf(s, ": %s", field->buf);
    
    The field->buf could be missing the nul byte. To prevent overflow, add the
    max size that the buf can be by using the event size and the field
    location.
    
      int max = iter->ent_size - offsetof(struct print_entry, buf);
    
      trace_seq_printf(s, ": %*.s", max, field->buf);
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231212084444.4619b8ce@gandalf.local.home
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Dec 9 17:10:58 2023 -0500

    tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing
    
    [ Upstream commit b55b0a0d7c4aa2dac3579aa7e6802d1f57445096 ]
    
    If a large event was added to the ring buffer that is larger than what the
    trace_seq can handle, it just drops the output:
    
     ~# cat /sys/kernel/tracing/trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 2/2   #P:8
     #
     #                                _-----=> irqs-off/BH-disabled
     #                               / _----=> need-resched
     #                              | / _---=> hardirq/softirq
     #                              || / _--=> preempt-depth
     #                              ||| / _-=> migrate-disable
     #                              |||| /     delay
     #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
     #              | |         |   |||||     |         |
                <...>-859     [001] .....   141.118951: tracing_mark_write           <...>-859     [001] .....   141.148201: tracing_mark_write: 78901234
    
    Instead, catch this case and add some context:
    
     ~# cat /sys/kernel/tracing/trace
     # tracer: nop
     #
     # entries-in-buffer/entries-written: 2/2   #P:8
     #
     #                                _-----=> irqs-off/BH-disabled
     #                               / _----=> need-resched
     #                              | / _---=> hardirq/softirq
     #                              || / _--=> preempt-depth
     #                              ||| / _-=> migrate-disable
     #                              |||| /     delay
     #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
     #              | |         |   |||||     |         |
                <...>-852     [001] .....   121.550551: tracing_mark_write[LINE TOO BIG]
                <...>-852     [001] .....   121.550581: tracing_mark_write: 78901234
    
    This now emulates the same output as trace_pipe.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231209171058.78c1a026@gandalf.local.home
    
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: change tty_write_lock()'s ndelay parameter to bool [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Thu Aug 10 11:14:39 2023 +0200

    tty: change tty_write_lock()'s ndelay parameter to bool
    
    [ Upstream commit af815336556df28f800669c58ab3bdad7d786b98 ]
    
    It's a yes-no parameter, so convert it to bool to be obvious.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230810091510.13006-6-jirislaby@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: don't check for signal_pending() in send_break() [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Tue Sep 19 10:51:55 2023 +0200

    tty: don't check for signal_pending() in send_break()
    
    [ Upstream commit fd99392b643b824813df2edbaebe26a2136d31e6 ]
    
    msleep_interruptible() will check on its own. So no need to do the check
    in send_break() before calling the above.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230919085156.1578-15-jirislaby@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: early return from send_break() on TTY_DRIVER_HARDWARE_BREAK [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Tue Sep 19 10:51:54 2023 +0200

    tty: early return from send_break() on TTY_DRIVER_HARDWARE_BREAK
    
    [ Upstream commit 66619686d187b4a6395316b7f39881e945dce4bc ]
    
    If the driver sets TTY_DRIVER_HARDWARE_BREAK, we leave ops->break_ctl()
    to the driver and return from send_break(). But we do it using a local
    variable and keep the code flowing through the end of the function.
    Instead, do 'return' immediately with the ops->break_ctl()'s return
    value.
    
    This way, we don't have to stuff the 'else' branch of the 'if' with the
    software break handling. And we can re-indent the function too.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230919085156.1578-14-jirislaby@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: use 'if' in send_break() instead of 'goto' [+ + +]
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Tue Sep 19 10:51:56 2023 +0200

    tty: use 'if' in send_break() instead of 'goto'
    
    [ Upstream commit 24f2cd019946fc2e88e632d2e24a34c2cc3f2be4 ]
    
    Now, the "jumped-over" code is simple enough to be put inside an 'if'.
    Do so to make it 'goto'-less.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20230919085156.1578-16-jirislaby@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 66aad7d8d3ec ("usb: cdc-acm: return correct error code on unsupported break")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
uio: Fix use-after-free in uio_open [+ + +]
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>
Date:   Thu Dec 21 17:57:43 2023 +0800

    uio: Fix use-after-free in uio_open
    
    commit 0c9ae0b8605078eafc3bea053cc78791e97ba2e2 upstream.
    
    core-1                          core-2
    -------------------------------------------------------
    uio_unregister_device           uio_open
                                    idev = idr_find()
    device_unregister(&idev->dev)
    put_device(&idev->dev)
    uio_device_release
                                    get_device(&idev->dev)
    kfree(idev)
    uio_free_minor(minor)
                                    uio_release
                                    put_device(&idev->dev)
                                    kfree(idev)
    -------------------------------------------------------
    
    In the core-1 uio_unregister_device(), the device_unregister will kfree
    idev when the idev->dev kobject ref is 1. But after core-1
    device_unregister, put_device and before doing kfree, the core-2 may
    get_device. Then:
    1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
    2. When core-2 do uio_release and put_device, the idev will be double
       freed.
    
    To address this issue, we can get idev atomic & inc idev reference with
    minor_lock.
    
    Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/1703152663-59949-1-git-send-email-guanghuifeng@linux.alibaba.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdc-acm: return correct error code on unsupported break [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Dec 7 14:26:30 2023 +0100

    usb: cdc-acm: return correct error code on unsupported break
    
    [ Upstream commit 66aad7d8d3ec5a3a8ec2023841bcec2ded5f65c9 ]
    
    In ACM support for sending breaks to devices is optional.
    If a device says that it doenot support sending breaks,
    the host must respect that.
    Given the number of optional features providing tty operations
    for each combination is not practical and errors need to be
    returned dynamically if unsupported features are requested.
    
    In case a device does not support break, we want the tty layer
    to treat that like it treats drivers that statically cannot
    support sending a break. It ignores the inability and does nothing.
    This patch uses EOPNOTSUPP to indicate that.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Fixes: 9e98966c7bb94 ("tty: rework break handling")
    Link: https://lore.kernel.org/r/20231207132639.18250-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: chipidea: wait controller resume finished for wakeup irq [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Thu Dec 28 19:07:52 2023 +0800

    usb: chipidea: wait controller resume finished for wakeup irq
    
    commit 128d849074d05545becf86e713715ce7676fc074 upstream.
    
    After the chipidea driver introduce extcon for id and vbus, it's able
    to wakeup from another irq source, in case the system with extcon ID
    cable, wakeup from usb ID cable and device removal, the usb device
    disconnect irq may come firstly before the extcon notifier while system
    resume, so we will get 2 "wakeup" irq, one for usb device disconnect;
    and one for extcon ID cable change(real wakeup event), current driver
    treat them as 2 successive wakeup irq so can't handle it correctly, then
    finally the usb irq can't be enabled. This patch adds a check to bypass
    further usb events before controller resume finished to fix it.
    
    Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support")
    cc:  <stable@vger.kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Link: https://lore.kernel.org/r/20231228110753.1755756-2-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart [+ + +]
Author: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Date:   Fri Dec 22 15:17:04 2023 +0530

    usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart
    
    commit e9d40b215e38480fd94c66b06d79045717a59e9c upstream.
    
    Current implementation blocks the running operations when Plug-out and
    Plug-In is performed continuously, process gets stuck in
    dwc3_thread_interrupt().
    
    Code Flow:
    
            CPU1
    
            ->Gadget_start
            ->dwc3_interrupt
            ->dwc3_thread_interrupt
            ->dwc3_process_event_buf
            ->dwc3_process_event_entry
            ->dwc3_endpoint_interrupt
            ->dwc3_ep0_interrupt
            ->dwc3_ep0_inspect_setup
            ->dwc3_ep0_stall_and_restart
    
    By this time if pending_list is not empty, it will get the next request
    on the given list and calls dwc3_gadget_giveback which will unmap request
    and call its complete() callback to notify upper layers that it has
    completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET,
    whereas it should be -ESHUTDOWN based on condition if not dwc->connected
    is true.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart")
    Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
    Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: mon: Fix atomicity violation in mon_bin_vma_fault [+ + +]
Author: Gui-Dong Han <2045gemini@gmail.com>
Date:   Fri Jan 5 13:24:12 2024 +0800

    usb: mon: Fix atomicity violation in mon_bin_vma_fault
    
    commit 2dd23cc4d0e6aa55cf9fb3b05f2f4165b01de81c upstream.
    
    In mon_bin_vma_fault():
        offset = vmf->pgoff << PAGE_SHIFT;
        if (offset >= rp->b_size)
            return VM_FAULT_SIGBUS;
        chunk_idx = offset / CHUNK_SIZE;
        pageptr = rp->b_vec[chunk_idx].pg;
    The code is executed without holding any lock.
    
    In mon_bin_vma_close():
        spin_lock_irqsave(&rp->b_lock, flags);
        rp->mmap_active--;
        spin_unlock_irqrestore(&rp->b_lock, flags);
    
    In mon_bin_ioctl():
        spin_lock_irqsave(&rp->b_lock, flags);
        if (rp->mmap_active) {
            ...
        } else {
            ...
            kfree(rp->b_vec);
            rp->b_vec  = vec;
            rp->b_size = size;
            ...
        }
        spin_unlock_irqrestore(&rp->b_lock, flags);
    
    Concurrent execution of mon_bin_vma_fault() with mon_bin_vma_close() and
    mon_bin_ioctl() could lead to atomicity violations. mon_bin_vma_fault()
    accesses rp->b_size and rp->b_vec without locking, risking array
    out-of-bounds access or use-after-free bugs due to possible modifications
    in mon_bin_ioctl().
    
    This possible bug is found by an experimental static analysis tool
    developed by our team, BassCheck[1]. This tool analyzes the locking APIs
    to extract function pairs that can be concurrently executed, and then
    analyzes the instructions in the paired functions to identify possible
    concurrency bugs including data races and atomicity violations. The above
    possible bug is reported when our tool analyzes the source code of
    Linux 6.2.
    
    To address this issue, it is proposed to add a spin lock pair in
    mon_bin_vma_fault() to ensure atomicity. With this patch applied, our tool
    never reports the possible bug, with the kernel configuration allyesconfig
    for x86_64. Due to the lack of associated hardware, we cannot test the
    patch in runtime testing, and just verify it according to the code logic.
    
    [1] https://sites.google.com/view/basscheck/
    
    Fixes: 19e6317d24c2 ("usb: mon: Fix a deadlock in usbmon between ...")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
    Link: https://lore.kernel.org/r/20240105052412.9377-1-2045gemini@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host() [+ + +]
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Thu Dec 28 19:07:53 2023 +0800

    usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
    
    commit ff2b89de471da942a4d853443688113a44fd35ed upstream.
    
    When CONFIG_USB_OTG is not set, mxs_phy_is_otg_host() will always return
    false. This behaviour is wrong. Since phy.last_event will always be set
    for either host or device mode. Therefore, CONFIG_USB_OTG condition
    can be removed.
    
    Fixes: 5eda42aebb76 ("usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host()")
    cc:  <stable@vger.kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20231228110753.1755756-3-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: class: fix typec_altmode_put_partner to put plugs [+ + +]
Author: RD Babiera <rdbabiera@google.com>
Date:   Wed Jan 3 18:17:55 2024 +0000

    usb: typec: class: fix typec_altmode_put_partner to put plugs
    
    commit 5962ded777d689cd8bf04454273e32228d7fb71f upstream.
    
    When typec_altmode_put_partner is called by a plug altmode upon release,
    the port altmode the plug belongs to will not remove its reference to the
    plug. The check to see if the altmode being released is a plug evaluates
    against the released altmode's partner instead of the calling altmode, so
    change adev in typec_altmode_put_partner to properly refer to the altmode
    being released.
    
    Because typec_altmode_set_partner calls get_device() on the port altmode,
    add partner_adev that points to the port altmode in typec_put_partner to
    call put_device() on. typec_altmode_set_partner is not called for port
    altmodes, so add a check in typec_altmode_release to prevent
    typec_altmode_put_partner() calls on port altmode release.
    
    Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
    Cc:  <stable@vger.kernel.org>
    Co-developed-by: Christian A. Ehrhardt <lk@c--e.de>
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Signed-off-by: RD Babiera <rdbabiera@google.com>
    Tested-by: Christian A. Ehrhardt <lk@c--e.de>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240103181754.2492492-2-rdbabiera@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtio-crypto: change code style [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Fri May 6 21:16:23 2022 +0800

    virtio-crypto: change code style
    
    [ Upstream commit 6fd763d155860eb7ea3a93c8b3bf926940ffa3fb ]
    
    Use temporary variable to make code easy to read and maintain.
            /* Pad cipher's parameters */
            vcrypto->ctrl.u.sym_create_session.op_type =
                    cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER);
            vcrypto->ctrl.u.sym_create_session.u.cipher.para.algo =
                    vcrypto->ctrl.header.algo;
            vcrypto->ctrl.u.sym_create_session.u.cipher.para.keylen =
                    cpu_to_le32(keylen);
            vcrypto->ctrl.u.sym_create_session.u.cipher.para.op =
                    cpu_to_le32(op);
    -->
            sym_create_session = &ctrl->u.sym_create_session;
            sym_create_session->op_type = cpu_to_le32(VIRTIO_CRYPTO_SYM_OP_CIPHER);
            sym_create_session->u.cipher.para.algo = ctrl->header.algo;
            sym_create_session->u.cipher.para.keylen = cpu_to_le32(keylen);
            sym_create_session->u.cipher.para.op = cpu_to_le32(op);
    
    The new style shows more obviously:
    - the variable we want to operate.
    - an assignment statement in a single line.
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Message-Id: <20220506131627.180784-2-pizhenwei@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session() [+ + +]
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Mon Nov 14 11:07:40 2022 +0000

    virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()
    
    commit b1d65f717cd6305a396a8738e022c6f7c65cfbe8 upstream.
    
    'vc_ctrl_req' is alloced in virtio_crypto_alg_skcipher_close_session(),
    and should be freed in the invalid ctrl_status->status error handling
    case. Otherwise there is a memory leak.
    
    Fixes: 0756ad15b1fe ("virtio-crypto: use private buffer for control request")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Message-Id: <20221114110740.537276-1-weiyongjun@huaweicloud.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Acked-by: zhenwei pi<pizhenwei@bytedance.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virtio-crypto: fix memory-leak [+ + +]
Author: lei he <helei.sig11@bytedance.com>
Date:   Mon Sep 19 15:51:58 2022 +0800

    virtio-crypto: fix memory-leak
    
    commit 1bedcf22c081a6e9943f09937b2da8d3ef52d20d upstream.
    
    Fix memory-leak for virtio-crypto akcipher request, this problem is
    introduced by 59ca6c93387d3(virtio-crypto: implement RSA algorithm).
    The leak can be reproduced and tested with the following script
    inside virtual machine:
    
    #!/bin/bash
    
    LOOP_TIMES=10000
    
    # required module: pkcs8_key_parser, virtio_crypto
    modprobe pkcs8_key_parser # if CONFIG_PKCS8_PRIVATE_KEY_PARSER=m
    modprobe virtio_crypto # if CONFIG_CRYPTO_DEV_VIRTIO=m
    rm -rf /tmp/data
    dd if=/dev/random of=/tmp/data count=1 bs=230
    
    # generate private key and self-signed cert
    openssl req -nodes -x509 -newkey rsa:2048 -keyout key.pem \
                    -outform der -out cert.der  \
                    -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=always.com/emailAddress=yy@always.com"
    # convert private key from pem to der
    openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER -out key.der
    
    # add key
    PRIV_KEY_ID=`cat key.der | keyctl padd asymmetric test_priv_key @s`
    echo "priv key id = "$PRIV_KEY_ID
    PUB_KEY_ID=`cat cert.der | keyctl padd asymmetric test_pub_key @s`
    echo "pub key id = "$PUB_KEY_ID
    
    # query key
    keyctl pkey_query $PRIV_KEY_ID 0
    keyctl pkey_query $PUB_KEY_ID 0
    
    # here we only run pkey_encrypt becasuse it is the fastest interface
    function bench_pub() {
            keyctl pkey_encrypt $PUB_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.pub
    }
    
    # do bench_pub in loop to obtain the memory leak
    for (( i = 0; i < ${LOOP_TIMES}; ++i )); do
            bench_pub
    done
    
    Signed-off-by: lei he <helei.sig11@bytedance.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Message-Id: <20220919075158.3625-1-helei.sig11@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

virtio-crypto: implement RSA algorithm [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Wed Mar 2 11:39:16 2022 +0800

    virtio-crypto: implement RSA algorithm
    
    [ Upstream commit 59ca6c93387d325e96577d8bd4c23c78c1491c11 ]
    
    Support rsa & pkcs1pad(rsa,sha1) with priority 150.
    
    Test with QEMU built-in backend, it works fine.
    1, The self-test framework of crypto layer works fine in guest kernel
    2, Test with Linux guest(with asym support), the following script
    test(note that pkey_XXX is supported only in a newer version of keyutils):
      - both public key & private key
      - create/close session
      - encrypt/decrypt/sign/verify basic driver operation
      - also test with kernel crypto layer(pkey add/query)
    
    All the cases work fine.
    
    rm -rf *.der *.pem *.pfx
    modprobe pkcs8_key_parser # if CONFIG_PKCS8_PRIVATE_KEY_PARSER=m
    rm -rf /tmp/data
    dd if=/dev/random of=/tmp/data count=1 bs=226
    
    openssl req -nodes -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -subj "/C=CN/ST=BJ/L=HD/O=qemu/OU=dev/CN=qemu/emailAddress=qemu@qemu.org"
    openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER -out key.der
    openssl x509 -in cert.pem -inform PEM -outform DER -out cert.der
    
    PRIV_KEY_ID=`cat key.der | keyctl padd asymmetric test_priv_key @s`
    echo "priv key id = "$PRIV_KEY_ID
    PUB_KEY_ID=`cat cert.der | keyctl padd asymmetric test_pub_key @s`
    echo "pub key id = "$PUB_KEY_ID
    
    keyctl pkey_query $PRIV_KEY_ID 0
    keyctl pkey_query $PUB_KEY_ID 0
    
    echo "Enc with priv key..."
    keyctl pkey_encrypt $PRIV_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.priv
    echo "Dec with pub key..."
    keyctl pkey_decrypt $PRIV_KEY_ID 0 /tmp/enc.priv enc=pkcs1 >/tmp/dec
    cmp /tmp/data /tmp/dec
    
    echo "Sign with priv key..."
    keyctl pkey_sign $PRIV_KEY_ID 0 /tmp/data enc=pkcs1 hash=sha1 > /tmp/sig
    echo "Verify with pub key..."
    keyctl pkey_verify $PRIV_KEY_ID 0 /tmp/data /tmp/sig enc=pkcs1 hash=sha1
    
    echo "Enc with pub key..."
    keyctl pkey_encrypt $PUB_KEY_ID 0 /tmp/data enc=pkcs1 >/tmp/enc.pub
    echo "Dec with priv key..."
    keyctl pkey_decrypt $PRIV_KEY_ID 0 /tmp/enc.pub enc=pkcs1 >/tmp/dec
    cmp /tmp/data /tmp/dec
    
    echo "Verify with pub key..."
    keyctl pkey_verify $PUB_KEY_ID 0 /tmp/data /tmp/sig enc=pkcs1 hash=sha1
    
    [1 compiling warning during development]
    Reported-by: kernel test robot <lkp@intel.com>
    
    Co-developed-by: lei he <helei.sig11@bytedance.com>
    Signed-off-by: lei he <helei.sig11@bytedance.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Link: https://lore.kernel.org/r/20220302033917.1295334-4-pizhenwei@bytedance.com
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org> #Kconfig tweaks
    Link: https://lore.kernel.org/r/20220308205309.2192502-1-nathan@kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

virtio-crypto: introduce akcipher service [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Wed Mar 2 11:39:15 2022 +0800

    virtio-crypto: introduce akcipher service
    
    [ Upstream commit 24e19590628b58578748eeaec8140bf9c9dc00d9 ]
    
    Introduce asymmetric service definition, asymmetric operations and
    several well known algorithms.
    
    Co-developed-by: lei he <helei.sig11@bytedance.com>
    Signed-off-by: lei he <helei.sig11@bytedance.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Link: https://lore.kernel.org/r/20220302033917.1295334-3-pizhenwei@bytedance.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

virtio-crypto: use private buffer for control request [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Fri May 6 21:16:24 2022 +0800

    virtio-crypto: use private buffer for control request
    
    [ Upstream commit 0756ad15b1fef287d4d8fa11bc36ea77a5c42e4a ]
    
    Originally, all of the control requests share a single buffer(
    ctrl & input & ctrl_status fields in struct virtio_crypto), this
    allows queue depth 1 only, the performance of control queue gets
    limited by this design.
    
    In this patch, each request allocates request buffer dynamically, and
    free buffer after request, so the scope protected by ctrl_lock also
    get optimized here.
    It's possible to optimize control queue depth in the next step.
    
    A necessary comment is already in code, still describe it again:
    /*
     * Note: there are padding fields in request, clear them to zero before
     * sending to host to avoid to divulge any information.
     * Ex, virtio_crypto_ctrl_request::ctrl::u::destroy_session::padding[48]
     */
    So use kzalloc to allocate buffer of struct virtio_crypto_ctrl_request.
    
    Potentially dereferencing uninitialized variables:
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Message-Id: <20220506131627.180784-3-pizhenwei@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

virtio-crypto: wait ctrl queue instead of busy polling [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Fri May 6 21:16:25 2022 +0800

    virtio-crypto: wait ctrl queue instead of busy polling
    
    [ Upstream commit 977231e8d45657871a86fe3c7bed94921d04e447 ]
    
    Originally, after submitting request into virtio crypto control
    queue, the guest side polls the result from the virt queue. This
    works like following:
        CPU0   CPU1               ...             CPUx  CPUy
         |      |                                  |     |
         \      \                                  /     /
          \--------spin_lock(&vcrypto->ctrl_lock)-------/
                               |
                     virtqueue add & kick
                               |
                      busy poll virtqueue
                               |
                  spin_unlock(&vcrypto->ctrl_lock)
                              ...
    
    There are two problems:
    1, The queue depth is always 1, the performance of a virtio crypto
       device gets limited. Multi user processes share a single control
       queue, and hit spin lock race from control queue. Test on Intel
       Platinum 8260, a single worker gets ~35K/s create/close session
       operations, and 8 workers get ~40K/s operations with 800% CPU
       utilization.
    2, The control request is supposed to get handled immediately, but
       in the current implementation of QEMU(v6.2), the vCPU thread kicks
       another thread to do this work, the latency also gets unstable.
       Tracking latency of virtio_crypto_alg_akcipher_close_session in 5s:
            usecs               : count     distribution
             0 -> 1          : 0        |                        |
             2 -> 3          : 7        |                        |
             4 -> 7          : 72       |                        |
             8 -> 15         : 186485   |************************|
            16 -> 31         : 687      |                        |
            32 -> 63         : 5        |                        |
            64 -> 127        : 3        |                        |
           128 -> 255        : 1        |                        |
           256 -> 511        : 0        |                        |
           512 -> 1023       : 0        |                        |
          1024 -> 2047       : 0        |                        |
          2048 -> 4095       : 0        |                        |
          4096 -> 8191       : 0        |                        |
          8192 -> 16383      : 2        |                        |
    This means that a CPU may hold vcrypto->ctrl_lock as long as 8192~16383us.
    
    To improve the performance of control queue, a request on control queue
    waits completion instead of busy polling to reduce lock racing, and gets
    completed by control queue callback.
        CPU0   CPU1               ...             CPUx  CPUy
         |      |                                  |     |
         \      \                                  /     /
          \--------spin_lock(&vcrypto->ctrl_lock)-------/
                               |
                     virtqueue add & kick
                               |
          ---------spin_unlock(&vcrypto->ctrl_lock)------
         /      /                                  \     \
         |      |                                  |     |
        wait   wait                               wait  wait
    
    Test this patch, the guest side get ~200K/s operations with 300% CPU
    utilization.
    
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Message-Id: <20220506131627.180784-4-pizhenwei@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio/vsock: fix logic which reduces credit update messages [+ + +]
Author: Arseniy Krasnov <avkrasnov@salutedevices.com>
Date:   Thu Dec 14 15:52:28 2023 +0300

    virtio/vsock: fix logic which reduces credit update messages
    
    [ Upstream commit 93b80887668226180ea5f5349cc728ca6dc700ab ]
    
    Add one more condition for sending credit update during dequeue from
    stream socket: when number of bytes in the rx queue is smaller than
    SO_RCVLOWAT value of the socket. This is actual for non-default value
    of SO_RCVLOWAT (e.g. not 1) - idea is to "kick" peer to continue data
    transmission, because we need at least SO_RCVLOWAT bytes in our rx
    queue to wake up user for reading data (in corner case it is also
    possible to stuck both tx and rx sides, this is why 'Fixes' is used).
    
    Fixes: b89d882dc9fc ("vsock/virtio: reduce credit update messages")
    Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC [+ + +]
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Wed Mar 2 11:39:14 2022 +0800

    virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC
    
    [ Upstream commit 13d640a3e9a3ac7ec694843d3d3b785e85fb8cb8 ]
    
    Base on the lastest virtio crypto spec, define VIRTIO_CRYPTO_NOSPC.
    
    Reviewed-by: Gonglei <arei.gonglei@huawei.com>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Link: https://lore.kernel.org/r/20220302033917.1295334-2-pizhenwei@bytedance.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Stable-dep-of: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO [+ + +]
Author: Jerry Hoemann <jerry.hoemann@hpe.com>
Date:   Wed Dec 13 14:53:38 2023 -0700

    watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO
    
    [ Upstream commit dced0b3e51dd2af3730efe14dd86b5e3173f0a65 ]
    
    Avoid unnecessary crashes by claiming only NMIs that are due to
    ERROR signalling or generated by the hpwdt hardware device.
    
    The code does this, but only for iLO5.
    
    The intent was to preserve legacy, Gen9 and earlier, semantics of
    using hpwdt for error containtment as hardware/firmware would signal
    fatal IO errors as an NMI with the expectation of hpwdt crashing
    the system.  Howerver, these IO errors should be received by hpwdt
    as an NMI_IO_CHECK.  So the test is overly permissive and should
    not be limited to only ilo5.
    
    We need to enable this protection for future iLOs not matching the
    current PCI IDs.
    
    Fixes: 62290a5c194b ("watchdog: hpwdt: Claim NMIs generated by iLO5")
    Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231213215340.495734-2-jerry.hoemann@hpe.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Sun Nov 12 18:32:51 2023 +0100

    watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling
    
    [ Upstream commit f33f5b1fd1be5f5106d16f831309648cb0f1c31d ]
    
    Users report about the unexpected behavior for setting timeouts above
    15 sec on Raspberry Pi. According to watchdog-api.rst the ioctl
    WDIOC_SETTIMEOUT shouldn't fail because of hardware limitations.
    But looking at the code shows that max_timeout based on the
    register value PM_WDOG_TIME_SET, which is the maximum.
    
    Since 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat
    in watchdog core") the watchdog core is able to handle this problem.
    
    This fix has been tested with watchdog-test from selftests.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217374
    Fixes: 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat in watchdog core")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231112173251.4827-1-wahrenst@gmx.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused [+ + +]
Author: Vignesh Raghavendra <vigneshr@ti.com>
Date:   Wed Dec 13 19:31:10 2023 +0530

    watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused
    
    [ Upstream commit c1a6edf3b541e44e78f10bc6024df779715723f1 ]
    
    Call runtime_pm_put*() if watchdog is not already started during probe and re
    enable it in watchdog start as required.
    
    On K3 SoCs, watchdogs and their corresponding CPUs are under same
    power-domain, so if the reference count of unused watchdogs aren't
    dropped, it will lead to CPU hotplug failures as Device Management
    firmware won't allow to turn off the power-domain due to dangling
    reference count.
    
    Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Tested-by: Manorit Chawdhry <m-chawdhry@ti.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231213140110.938129-1-vigneshr@ti.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

watchdog: set cdev owner before adding [+ + +]
Author: Curtis Klein <curtis.klein@hpe.com>
Date:   Tue Dec 5 11:05:22 2023 -0800

    watchdog: set cdev owner before adding
    
    [ Upstream commit 38d75297745f04206db9c29bdd75557f0344c7cc ]
    
    When the new watchdog character device is registered, it becomes
    available for opening. This creates a race where userspace may open the
    device before the character device's owner is set. This results in an
    imbalance in module_get calls as the cdev_get in cdev_open will not
    increment the reference count on the watchdog driver module.
    
    This causes problems when the watchdog character device is released as
    the module loader's reference will also be released. This makes it
    impossible to open the watchdog device later on as it now appears that
    the module is being unloaded. The open will fail with -ENXIO from
    chrdev_open.
    
    The legacy watchdog device will fail with -EBUSY from the try_module_get
    in watchdog_open because it's module owner is the watchdog core module
    so it can still be opened but it will fail to get a refcount on the
    underlying watchdog device driver.
    
    Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev")
    Signed-off-by: Curtis Klein <curtis.klein@hpe.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231205190522.55153-1-curtis.klein@hpe.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath11k: Defer on rproc_get failure [+ + +]
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Fri Oct 27 08:57:18 2023 +0200

    wifi: ath11k: Defer on rproc_get failure
    
    [ Upstream commit 2a3ec40b98b46c339adb57313d3b933ee5e7a8e8 ]
    
    If we already have gotten the rproc_handle (meaning the "qcom,rproc"
    property is defined in the devicetree), it's a valid state that the
    remoteproc module hasn't probed yet so we should defer probing instead
    of just failing to probe.
    
    This resolves a race condition when the ath11k driver probes and fails
    before the wpss remoteproc driver has probed, like the following:
    
      [    6.232360] ath11k 17a10040.wifi: failed to get rproc
      [    6.232366] ath11k 17a10040.wifi: failed to get rproc: -22
      [    6.232478] ath11k: probe of 17a10040.wifi failed with error -22
           ...
      [    6.252415] remoteproc remoteproc2: 8a00000.remoteproc is available
      [    6.252776] remoteproc remoteproc2: powering up 8a00000.remoteproc
      [    6.252781] remoteproc remoteproc2: Booting fw image qcom/qcm6490/fairphone5/wpss.mdt, size 7188
    
    So, defer the probe if we hit that so we can retry later once the wpss
    remoteproc is available.
    
    Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01264-QCAMSLSWPLZ-1.37886.3
    
    Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20231027-ath11k-rproc-defer-v1-1-f6b6a812cd18@fairphone.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: libertas: stop selecting wext [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 8 16:34:03 2023 +0100

    wifi: libertas: stop selecting wext
    
    [ Upstream commit 8170b04c2c92eee52ea50b96db4c54662197e512 ]
    
    Libertas no longer references the iw_handler infrastructure or wext_spy,
    so neither of the 'select' statements are used any more.
    
    Fixes: e86dc1ca4676 ("Libertas: cfg80211 support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231108153409.1065286-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: configure BSSID consistently when starting AP [+ + +]
Author: David Lin <yu-hao.lin@nxp.com>
Date:   Fri Dec 15 08:51:18 2023 +0800

    wifi: mwifiex: configure BSSID consistently when starting AP
    
    commit f0dd488e11e71ac095df7638d892209c629d9af2 upstream.
    
    AP BSSID configuration is missing at AP start.  Without this fix, FW returns
    STA interface MAC address after first init.  When hostapd restarts, it gets MAC
    address from netdev before driver sets STA MAC to netdev again. Now MAC address
    between hostapd and net interface are different causes STA cannot connect to
    AP.  After that MAC address of uap0 mlan0 become the same. And issue disappears
    after following hostapd restart (another issue is AP/STA MAC address become the
    same).
    
    This patch fixes the issue cleanly.
    
    Signed-off-by: David Lin <yu-hao.lin@nxp.com>
    Fixes: 12190c5d80bd ("mwifiex: add cfg80211 start_ap and stop_ap handlers")
    Cc: stable@vger.kernel.org
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Tested-by: Rafael Beims <rafael.beims@toradex.com> # Verdin iMX8MP/SD8997 SD
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231215005118.17031-1-yu-hao.lin@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: rtlwifi: add calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:29 2023 +0800

    wifi: rtlwifi: add calculate_bit_shift()
    
    [ Upstream commit 52221dfddbbfb5b4e029bb2efe9bb7da33ec1e46 ]
    
    There are many same functions like _rtl88e_phy_calculate_bit_shift(),
    _rtl92c_phy_calculate_bit_shift() and so on. And these functions can
    cause undefined bitwise shift behavior. Add calculate_bit_shift() to
    replace them and fix undefined behavior in subsequent patches.
    
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-2-suhui@nfschina.com
    Stable-dep-of: 969bc926f04b ("wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri Nov 24 10:47:17 2023 +0200

    wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors
    
    commit 5894d0089cbc146063dcc0239a78ede0a8142efb upstream.
    
    The rtlwifi driver comes with custom code to write into PCIe Link
    Control register. RMW access for the Link Control register requires
    locking that is already provided by the standard PCIe capability
    accessors.
    
    Convert the custom RMW code writing into LNKCTL register to standard
    RMW capability accessors. The accesses are changed to cover the full
    LNKCTL register instead of touching just a single byte of the register.
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231124084725.12738-3-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri Nov 24 10:47:16 2023 +0200

    wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code
    
    commit b3943b3c2971444364e03224cfc828c5789deada upstream.
    
    Ever since introduction in the commit 0c8173385e54 ("rtl8192ce: Add new
    driver") the rtlwifi code has, according to comments, attempted to
    disable/enable ASPM of the upstream bridge by writing into its LNKCTL
    register. However, the code has never been correct because it performs
    the writes to the device instead of the upstream bridge.
    
    Worse yet, the offset where the PCIe capabilities reside is derived
    from the offset of the upstream bridge. As a result, the write will use
    an offset on the device that does not relate to the LNKCTL register
    making the ASPM disable/enable code outright dangerous.
    
    Because of those problems, there is no indication that the driver needs
    disable/enable ASPM on the upstream bridge. As the Capabilities offset
    is not correctly calculated for the write to target device's LNKCTL
    register, the code is not disabling/enabling device's ASPM either.
    Therefore, just remove the upstream bridge related ASPM disable/enable
    code entirely.
    
    The upstream bridge related ASPM code was the only user of the struct
    mp_adapter members num4bytes, pcibridge_pciehdr_offset, and
    pcibridge_linkctrlreg so those are removed as well.
    
    Note: This change does not remove the code related to changing the
    device's ASPM on purpose (which is independent of this flawed code
    related to upstream bridge's ASPM).
    
    Suggested-by: Bjorn Helgaas <bhelgaas@kernel.org>
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Fixes: 886e14b65a8f ("rtlwifi: Eliminate raw reads and writes from PCIe portion")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231124084725.12738-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:31 2023 +0800

    wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift()
    
    [ Upstream commit 969bc926f04b438676768aeffffffb050e480b62 ]
    
    Using calculate_bit_shift() to replace _rtl88e_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: f0eb856e0b6c ("rtlwifi: rtl8188ee: Add new driver")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-4-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192c: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:32 2023 +0800

    wifi: rtlwifi: rtl8192c: using calculate_bit_shift()
    
    [ Upstream commit 1dedc3a6699d827d345019e921b8d8f37f694333 ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 4295cd254af3 ("rtlwifi: Move common parts of rtl8192ce/phy.c")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-5-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192ce: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:34 2023 +0800

    wifi: rtlwifi: rtl8192ce: using calculate_bit_shift()
    
    [ Upstream commit 3d03e8231031bcc65a48cd88ef9c71b6524ce70b ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-7-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192cu: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:33 2023 +0800

    wifi: rtlwifi: rtl8192cu: using calculate_bit_shift()
    
    [ Upstream commit f4088c8fcbabadad9dd17d17ae9ba24e9e3221ec ]
    
    Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift().
    And fix an undefined bitwise shift behavior problem.
    
    Fixes: f0a39ae738d6 ("rtlwifi: rtl8192cu: Add routine phy")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-6-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192de: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:35 2023 +0800

    wifi: rtlwifi: rtl8192de: using calculate_bit_shift()
    
    [ Upstream commit b8b2baad2e652042cf8b6339939ac2f4e6f53de4 ]
    
    Using calculate_bit_shift() to replace _rtl92d_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-8-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192ee: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:36 2023 +0800

    wifi: rtlwifi: rtl8192ee: using calculate_bit_shift()
    
    [ Upstream commit 63526897fc0d086069bcab67c3a112caaec751cb ]
    
    Using calculate_bit_shift() to replace _rtl92ee_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: b1a3bfc97cd9 ("rtlwifi: rtl8192ee: Move driver from staging to the regular tree")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-9-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8192se: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:37 2023 +0800

    wifi: rtlwifi: rtl8192se: using calculate_bit_shift()
    
    [ Upstream commit ac32b9317063b101a8ff3d3e885f76f87a280419 ]
    
    Using calculate_bit_shift() to replace _rtl92s_phy_calculate_bit_shift().
    And fix the undefined bitwise shift behavior problem.
    
    Fixes: d15853163bea ("rtlwifi: rtl8192se: Merge phy routines")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-10-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8821ae: phy: fix an undefined bitwise shift behavior [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Mon Nov 27 09:35:13 2023 +0800

    wifi: rtlwifi: rtl8821ae: phy: fix an undefined bitwise shift behavior
    
    [ Upstream commit bc8263083af60e7e57c6120edbc1f75d6c909a35 ]
    
    Clang static checker warns:
    
    drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:184:49:
            The result of the left shift is undefined due to shifting by '32',
            which is greater or equal to the width of type 'u32'.
            [core.UndefinedBinaryOperatorResult]
    
    If the value of the right operand is negative or is greater than or
    equal to the width of the promoted left operand, the behavior is
    undefined.[1][2]
    
    For example, when using different gcc's compilation optimization options
    (-O0 or -O2), the result of '(u32)data << 32' is different. One is 0, the
    other is old value of data. Let _rtl8821ae_phy_calculate_bit_shift()'s
    return value less than 32 to fix this problem. Warn if bitmask is zero.
    
    [1] https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type
    [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
    
    Fixes: 21e4b0726dc6 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231127013511.26694-2-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtw88: fix RX filter in FIF_ALLMULTI flag [+ + +]
Author: Chih-Kang Chang <gary.chang@realtek.com>
Date:   Fri Nov 3 10:08:51 2023 +0800

    wifi: rtw88: fix RX filter in FIF_ALLMULTI flag
    
    [ Upstream commit 53ee0b3b99edc6a47096bffef15695f5a895386f ]
    
    The broadcast packets will be filtered in the FIF_ALLMULTI flag in
    the original code, which causes beacon packets to be filtered out
    and disconnection. Therefore, we fix it.
    
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231103020851.102238-1-pkshih@realtek.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/kvm: Do not try to disable kvmclock if it was not enabled [+ + +]
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Tue Dec 5 03:45:01 2023 +0300

    x86/kvm: Do not try to disable kvmclock if it was not enabled
    
    commit 1c6d984f523f67ecfad1083bb04c55d91977bb15 upstream.
    
    kvm_guest_cpu_offline() tries to disable kvmclock regardless if it is
    present in the VM. It leads to write to a MSR that doesn't exist on some
    configurations, namely in TDX guest:
    
            unchecked MSR access error: WRMSR to 0x12 (tried to write 0x0000000000000000)
            at rIP: 0xffffffff8110687c (kvmclock_disable+0x1c/0x30)
    
    kvmclock enabling is gated by CLOCKSOURCE and CLOCKSOURCE2 KVM paravirt
    features.
    
    Do not disable kvmclock if it was not enabled.
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Fixes: c02027b5742b ("x86/kvm: Disable kvmclock on all CPUs on shutdown")
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Wanpeng Li <wanpengli@tencent.com>
    Cc: stable@vger.kernel.org
    Message-Id: <20231205004510.27164-6-kirill.shutemov@linux.intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/lib: Fix overflow when counting digits [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Nov 2 17:49:01 2023 +0000

    x86/lib: Fix overflow when counting digits
    
    [ Upstream commit a24d61c609813963aacc9f6ec8343f4fcaac7243 ]
    
    tl;dr: The num_digits() function has a theoretical overflow issue.
    But it doesn't affect any actual in-tree users.  Fix it by using
    a larger type for one of the local variables.
    
    Long version:
    
    There is an overflow in variable m in function num_digits when val
    is >= 1410065408 which leads to the digit calculation loop to
    iterate more times than required. This results in either more
    digits being counted or in some cases (for example where val is
    1932683193) the value of m eventually overflows to zero and the
    while loop spins forever).
    
    Currently the function num_digits is currently only being used for
    small values of val in the SMP boot stage for digit counting on the
    number of cpus and NUMA nodes, so the overflow is never encountered.
    However it is useful to fix the overflow issue in case the function
    is used for other purposes in the future. (The issue was discovered
    while investigating the digit counting performance in various
    kernel helper functions rather than any real-world use-case).
    
    The simplest fix is to make m a long long, the overhead in
    multiplication speed for a long long is very minor for small values
    of val less than 10000 on modern processors. The alternative
    fix is to replace the multiplication with a constant division
    by 10 loop (this compiles down to an multiplication and shift)
    without needing to make m a long long, but this is slightly slower
    than the fix in this commit when measured on a range of x86
    processors).
    
    [ dhansen: subject and changelog tweaks ]
    
    Fixes: 646e29a1789a ("x86: Improve the printout of the SMP bootup CPU table")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20231102174901.2590325-1-colin.i.king%40gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xen-netback: don't produce zero-size SKB frags [+ + +]
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Jan 8 10:38:12 2024 +0100

    xen-netback: don't produce zero-size SKB frags
    
    commit c7ec4f2d684e17d69bbdd7c4324db0ef5daac26a upstream.
    
    While frontends may submit zero-size requests (wasting a precious slot),
    core networking code as of at least 3ece782693c4b ("sock: skb_copy_ubufs
    support for compound pages") can't deal with SKBs when they have all
    zero-size fragments. Respond to empty requests right when populating
    fragments; all further processing is fragment based and hence won't
    encounter these empty requests anymore.
    
    In a way this should have been that way from the beginning: When no data
    is to be transferred for a particular request, there's not even a point
    in validating the respective grant ref. That's no different from e.g.
    passing NULL into memcpy() when at the same time the size is 0.
    
    This is XSA-448 / CVE-2023-46838.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>