--- /dev/null
+From 7d3e4e9d3bde9c8bd8914d47ddaa90e0d0ffbcab Mon Sep 17 00:00:00 2001
+From: Mikko Rapeli <mikko.rapeli@linaro.org>
+Date: Thu, 21 Sep 2023 17:57:22 +0300
+Subject: arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y
+
+From: Mikko Rapeli <mikko.rapeli@linaro.org>
+
+commit 7d3e4e9d3bde9c8bd8914d47ddaa90e0d0ffbcab upstream.
+
+There is no code for this config option and enabling it in defconfig
+causes warnings from tools which are detecting unused and obsolete
+kernel config flags since the flag will be completely missing from
+effective build config after "make olddefconfig".
+
+Fixes yocto kernel recipe build time warning:
+
+WARNING: [kernel config]: This BSP contains fragments with warnings:
+...
+[INFO]: the following symbols were not found in the active
+configuration:
+ - CONFIG_COMMON_CLK_NPCM8XX
+
+The flag was added with commit 45472f1e5348c7b755b4912f2f529ec81cea044b
+v5.19-rc4-15-g45472f1e5348 so 6.1 and 6.4 stable kernel trees are
+affected.
+
+Fixes: 45472f1e5348c7b755b4912f2f529ec81cea044b ("arm64: defconfig: Add Nuvoton NPCM family support")
+Cc: stable@kernel.org
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: Bjorn Andersson <quic_bjorande@quicinc.com>
+Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Cc: Konrad Dybcio <konrad.dybcio@linaro.org>
+Cc: Neil Armstrong <neil.armstrong@linaro.org>
+Cc: Tomer Maimon <tmaimon77@gmail.com>
+Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
+Cc: Jon Mason <jon.mason@arm.com>
+Cc: Jon Mason <jdmason@kudzu.us>
+Cc: Ross Burton <ross@burtonini.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/configs/defconfig | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm64/configs/defconfig
++++ b/arch/arm64/configs/defconfig
+@@ -1050,7 +1050,6 @@ CONFIG_COMMON_CLK_FSL_SAI=y
+ CONFIG_COMMON_CLK_S2MPS11=y
+ CONFIG_COMMON_CLK_PWM=y
+ CONFIG_COMMON_CLK_VC5=y
+-CONFIG_COMMON_CLK_NPCM8XX=y
+ CONFIG_COMMON_CLK_BD718XX=m
+ CONFIG_CLK_RASPBERRYPI=m
+ CONFIG_CLK_IMX8MM=y
--- /dev/null
+From 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Fri, 8 Sep 2023 20:04:52 +0900
+Subject: ata: libata-core: Do not register PM operations for SAS ports
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 upstream.
+
+libsas does its own domain based power management of ports. For such
+ports, libata should not use a device type defining power management
+operations as executing these operations for suspend/resume in addition
+to libsas calls to ata_sas_port_suspend() and ata_sas_port_resume() is
+not necessary (and likely dangerous to do, even though problems are not
+seen currently).
+
+Introduce the new ata_port_sas_type device_type for ports managed by
+libsas. This new device type is used in ata_tport_add() and is defined
+without power management operations.
+
+Fixes: 2fcbdcb4c802 ("[SCSI] libata: export ata_port suspend/resume infrastructure for sas")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: John Garry <john.g.garry@oracle.com>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 2 +-
+ drivers/ata/libata-transport.c | 9 ++++++++-
+ drivers/ata/libata.h | 2 ++
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -5173,7 +5173,7 @@ EXPORT_SYMBOL_GPL(ata_host_resume);
+ #endif
+
+ const struct device_type ata_port_type = {
+- .name = "ata_port",
++ .name = ATA_PORT_TYPE_NAME,
+ #ifdef CONFIG_PM
+ .pm = &ata_port_pm_ops,
+ #endif
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -266,6 +266,10 @@ void ata_tport_delete(struct ata_port *a
+ put_device(dev);
+ }
+
++static const struct device_type ata_port_sas_type = {
++ .name = ATA_PORT_TYPE_NAME,
++};
++
+ /** ata_tport_add - initialize a transport ATA port structure
+ *
+ * @parent: parent device
+@@ -283,7 +287,10 @@ int ata_tport_add(struct device *parent,
+ struct device *dev = &ap->tdev;
+
+ device_initialize(dev);
+- dev->type = &ata_port_type;
++ if (ap->flags & ATA_FLAG_SAS_HOST)
++ dev->type = &ata_port_sas_type;
++ else
++ dev->type = &ata_port_type;
+
+ dev->parent = parent;
+ ata_host_get(ap->host);
+--- a/drivers/ata/libata.h
++++ b/drivers/ata/libata.h
+@@ -30,6 +30,8 @@ enum {
+ ATA_DNXFER_QUIET = (1 << 31),
+ };
+
++#define ATA_PORT_TYPE_NAME "ata_port"
++
+ extern atomic_t ata_print_id;
+ extern int atapi_passthru16;
+ extern int libata_fua;
--- /dev/null
+From 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Mon, 4 Sep 2023 20:38:13 +0900
+Subject: ata: libata-core: Fix ata_port_request_pm() locking
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 upstream.
+
+The function ata_port_request_pm() checks the port flag
+ATA_PFLAG_PM_PENDING and calls ata_port_wait_eh() if this flag is set to
+ensure that power management operations for a port are not scheduled
+simultaneously. However, this flag check is done without holding the
+port lock.
+
+Fix this by taking the port lock on entry to the function and checking
+the flag under this lock. The lock is released and re-taken if
+ata_port_wait_eh() needs to be called. The two WARN_ON() macros checking
+that the ATA_PFLAG_PM_PENDING flag was cleared are removed as the first
+call is racy and the second one done without holding the port lock.
+
+Fixes: 5ef41082912b ("ata: add ata port system PM callbacks")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4981,17 +4981,19 @@ static void ata_port_request_pm(struct a
+ struct ata_link *link;
+ unsigned long flags;
+
+- /* Previous resume operation might still be in
+- * progress. Wait for PM_PENDING to clear.
++ spin_lock_irqsave(ap->lock, flags);
++
++ /*
++ * A previous PM operation might still be in progress. Wait for
++ * ATA_PFLAG_PM_PENDING to clear.
+ */
+ if (ap->pflags & ATA_PFLAG_PM_PENDING) {
++ spin_unlock_irqrestore(ap->lock, flags);
+ ata_port_wait_eh(ap);
+- WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
++ spin_lock_irqsave(ap->lock, flags);
+ }
+
+- /* request PM ops to EH */
+- spin_lock_irqsave(ap->lock, flags);
+-
++ /* Request PM operation to EH */
+ ap->pm_mesg = mesg;
+ ap->pflags |= ATA_PFLAG_PM_PENDING;
+ ata_for_each_link(link, ap, HOST_FIRST) {
+@@ -5003,10 +5005,8 @@ static void ata_port_request_pm(struct a
+
+ spin_unlock_irqrestore(ap->lock, flags);
+
+- if (!async) {
++ if (!async)
+ ata_port_wait_eh(ap);
+- WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
+- }
+ }
+
+ /*
--- /dev/null
+From 84d76529c650f887f1e18caee72d6f0589e1baf9 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Sat, 26 Aug 2023 13:07:36 +0900
+Subject: ata: libata-core: Fix port and device removal
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 84d76529c650f887f1e18caee72d6f0589e1baf9 upstream.
+
+Whenever an ATA adapter driver is removed (e.g. rmmod),
+ata_port_detach() is called repeatedly for all the adapter ports to
+remove (unload) the devices attached to the port and delete the port
+device itself. Removing of devices is done using libata EH with the
+ATA_PFLAG_UNLOADING port flag set. This causes libata EH to execute
+ata_eh_unload() which disables all devices attached to the port.
+
+ata_port_detach() finishes by calling scsi_remove_host() to remove the
+scsi host associated with the port. This function will trigger the
+removal of all scsi devices attached to the host and in the case of
+disks, calls to sd_shutdown() which will flush the device write cache
+and stop the device. However, given that the devices were already
+disabled by ata_eh_unload(), the synchronize write cache command and
+start stop unit commands fail. E.g. running "rmmod ahci" with first
+removing sd_mod results in error messages like:
+
+ata13.00: disable device
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+sd 0:0:0:0: [sda] Stopping disk
+sd 0:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+
+Fix this by removing all scsi devices of the ata devices connected to
+the port before scheduling libata EH to disable the ATA devices.
+
+Fixes: 720ba12620ee ("[PATCH] libata-hp: update unload-unplug")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -5906,11 +5906,30 @@ static void ata_port_detach(struct ata_p
+ if (!ap->ops->error_handler)
+ goto skip_eh;
+
+- /* tell EH we're leaving & flush EH */
++ /* Wait for any ongoing EH */
++ ata_port_wait_eh(ap);
++
++ mutex_lock(&ap->scsi_scan_mutex);
+ spin_lock_irqsave(ap->lock, flags);
++
++ /* Remove scsi devices */
++ ata_for_each_link(link, ap, HOST_FIRST) {
++ ata_for_each_dev(dev, link, ALL) {
++ if (dev->sdev) {
++ spin_unlock_irqrestore(ap->lock, flags);
++ scsi_remove_device(dev->sdev);
++ spin_lock_irqsave(ap->lock, flags);
++ dev->sdev = NULL;
++ }
++ }
++ }
++
++ /* Tell EH to disable all devices */
+ ap->pflags |= ATA_PFLAG_UNLOADING;
+ ata_port_schedule_eh(ap);
++
+ spin_unlock_irqrestore(ap->lock, flags);
++ mutex_unlock(&ap->scsi_scan_mutex);
+
+ /* wait till EH commits suicide */
+ ata_port_wait_eh(ap);
--- /dev/null
+From 753a4d531bc518633ea88ac0ed02b25a16823d51 Mon Sep 17 00:00:00 2001
+From: Matthias Schiffer <mschiffer@universe-factory.net>
+Date: Fri, 22 Sep 2023 22:55:16 +0200
+Subject: ata: libata-sata: increase PMP SRST timeout to 10s
+
+From: Matthias Schiffer <mschiffer@universe-factory.net>
+
+commit 753a4d531bc518633ea88ac0ed02b25a16823d51 upstream.
+
+On certain SATA controllers, softreset fails after wakeup from S2RAM with
+the message "softreset failed (1st FIS failed)", sometimes resulting in
+drives not being detected again. With the increased timeout, this issue
+is avoided. Instead, "softreset failed (device not ready)" is now
+logged 1-2 times; this later failure seems to cause fewer problems
+however, and the drives are detected reliably once they've spun up and
+the probe is retried.
+
+The issue was observed with the primary SATA controller of the QNAP
+TS-453B, which is an "Intel Corporation Celeron/Pentium Silver Processor
+SATA Controller [8086:31e3] (rev 06)" integrated in the Celeron J4125 CPU,
+and the following drives:
+
+- Seagate IronWolf ST12000VN0008
+- Seagate IronWolf ST8000NE0004
+
+The SATA controller seems to be more relevant to this issue than the
+drives, as the same drives are always detected reliably on the secondary
+SATA controller on the same board (an ASMedia 106x) without any "softreset
+failed" errors even without the increased timeout.
+
+Fixes: e7d3ef13d52a ("libata: change drive ready wait after hard reset to 5s")
+Cc: stable@vger.kernel.org
+Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/libata.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/libata.h
++++ b/include/linux/libata.h
+@@ -253,7 +253,7 @@ enum {
+ * advised to wait only for the following duration before
+ * doing SRST.
+ */
+- ATA_TMOUT_PMP_SRST_WAIT = 5000,
++ ATA_TMOUT_PMP_SRST_WAIT = 10000,
+
+ /* When the LPM policy is set to ATA_LPM_MAX_POWER, there might
+ * be a spurious PHY event, so ignore the first PHY event that
--- /dev/null
+From 41bc46c12a8053a1b3279a379bd6b5e87b045b85 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+Date: Thu, 7 Sep 2023 22:06:51 +0200
+Subject: bpf: Add override check to kprobe multi link attach
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+commit 41bc46c12a8053a1b3279a379bd6b5e87b045b85 upstream.
+
+Currently the multi_kprobe link attach does not check error
+injection list for programs with bpf_override_return helper
+and allows them to attach anywhere. Adding the missing check.
+
+Fixes: 0dcac2725406 ("bpf: Add multi kprobe link")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
+Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/bpf/20230907200652.926951-1-jolsa@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/bpf_trace.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/kernel/trace/bpf_trace.c
++++ b/kernel/trace/bpf_trace.c
+@@ -2684,6 +2684,17 @@ static void symbols_swap_r(void *a, void
+ }
+ }
+
++static int addrs_check_error_injection_list(unsigned long *addrs, u32 cnt)
++{
++ u32 i;
++
++ for (i = 0; i < cnt; i++) {
++ if (!within_error_injection_list(addrs[i]))
++ return -EINVAL;
++ }
++ return 0;
++}
++
+ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
+ {
+ struct bpf_kprobe_multi_link *link = NULL;
+@@ -2761,6 +2772,11 @@ int bpf_kprobe_multi_link_attach(const u
+ goto error;
+ }
+
++ if (prog->kprobe_override && addrs_check_error_injection_list(addrs, cnt)) {
++ err = -EINVAL;
++ goto error;
++ }
++
+ link = kzalloc(sizeof(*link), GFP_KERNEL);
+ if (!link) {
+ err = -ENOMEM;
--- /dev/null
+From c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Fri, 15 Sep 2023 10:34:28 -0700
+Subject: bpf: Fix BTF_ID symbol generation collision in tools/
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 upstream.
+
+Marcus and Satya reported an issue where BTF_ID macro generates same
+symbol in separate objects and that breaks final vmlinux link.
+
+ ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
+ '__BTF_ID__struct__cgroup__624' is already defined
+
+This can be triggered under specific configs when __COUNTER__ happens to
+be the same for the same symbol in two different translation units,
+which is already quite unlikely to happen.
+
+Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
+not a complete fix, but it would help for now and meanwhile we can work
+on better solution as suggested by Andrii.
+
+Cc: stable@vger.kernel.org
+Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
+Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
+Debugged-by: Nathan Chancellor <nathan@kernel.org>
+Co-developed-by: Jiri Olsa <jolsa@kernel.org>
+Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-2-263fc519c21f@google.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/include/linux/btf_ids.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/include/linux/btf_ids.h
++++ b/tools/include/linux/btf_ids.h
+@@ -38,7 +38,7 @@ asm( \
+ ____BTF_ID(symbol)
+
+ #define __ID(prefix) \
+- __PASTE(prefix, __COUNTER__)
++ __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
+
+ /*
+ * The BTF_ID defines unique symbol for each ID pointing
--- /dev/null
+From 8f908db77782630c45ba29dac35c434b5ce0b730 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+Date: Fri, 15 Sep 2023 10:34:27 -0700
+Subject: bpf: Fix BTF_ID symbol generation collision
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+commit 8f908db77782630c45ba29dac35c434b5ce0b730 upstream.
+
+Marcus and Satya reported an issue where BTF_ID macro generates same
+symbol in separate objects and that breaks final vmlinux link.
+
+ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
+'__BTF_ID__struct__cgroup__624' is already defined
+
+This can be triggered under specific configs when __COUNTER__ happens to
+be the same for the same symbol in two different translation units,
+which is already quite unlikely to happen.
+
+Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
+not a complete fix, but it would help for now and meanwhile we can work
+on better solution as suggested by Andrii.
+
+Cc: stable@vger.kernel.org
+Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
+Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
+Debugged-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-1-263fc519c21f@google.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/btf_ids.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/btf_ids.h
++++ b/include/linux/btf_ids.h
+@@ -49,7 +49,7 @@ word \
+ ____BTF_ID(symbol, word)
+
+ #define __ID(prefix) \
+- __PASTE(prefix, __COUNTER__)
++ __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
+
+ /*
+ * The BTF_ID defines unique symbol for each ID pointing
--- /dev/null
+From 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Mon, 18 Sep 2023 10:34:51 -0400
+Subject: btrfs: properly report 0 avail for very full file systems
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c upstream.
+
+A user reported some issues with smaller file systems that get very
+full. While investigating this issue I noticed that df wasn't showing
+100% full, despite having 0 chunk space and having < 1MiB of available
+metadata space.
+
+This turns out to be an overflow issue, we're doing:
+
+ total_available_metadata_space - SZ_4M < global_block_rsv_size
+
+to determine if there's not enough space to make metadata allocations,
+which overflows if total_available_metadata_space is < 4M. Fix this by
+checking to see if our available space is greater than the 4M threshold.
+This makes df properly report 100% usage on the file system.
+
+CC: stable@vger.kernel.org # 4.14+
+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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/super.c
++++ b/fs/btrfs/super.c
+@@ -2418,7 +2418,7 @@ static int btrfs_statfs(struct dentry *d
+ * calculated f_bavail.
+ */
+ if (!mixed && block_rsv->space_info->full &&
+- total_free_meta - thresh < block_rsv->size)
++ (total_free_meta < thresh || total_free_meta - thresh < block_rsv->size))
+ buf->f_bavail = 0;
+
+ buf->f_type = BTRFS_SUPER_MAGIC;
--- /dev/null
+From cc39f9ccb82426e576734b493e1777ea01b144a8 Mon Sep 17 00:00:00 2001
+From: YuBiao Wang <YuBiao.Wang@amd.com>
+Date: Fri, 15 Sep 2023 10:47:50 +0800
+Subject: drm/amdkfd: Use gpu_offset for user queue's wptr
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: YuBiao Wang <YuBiao.Wang@amd.com>
+
+commit cc39f9ccb82426e576734b493e1777ea01b144a8 upstream.
+
+Directly use tbo's start address will miss the domain start offset. Need
+to use gpu_offset instead.
+
+Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+@@ -201,7 +201,7 @@ static int add_queue_mes(struct device_q
+
+ if (q->wptr_bo) {
+ wptr_addr_off = (uint64_t)q->properties.write_ptr & (PAGE_SIZE - 1);
+- queue_input.wptr_mc_addr = ((uint64_t)q->wptr_bo->tbo.resource->start << PAGE_SHIFT) + wptr_addr_off;
++ queue_input.wptr_mc_addr = amdgpu_bo_gpu_offset(q->wptr_bo) + wptr_addr_off;
+ }
+
+ queue_input.is_kfd_process = 1;
--- /dev/null
+From b7599d241778d0b10cdf7a5c755aa7db9b83250c Mon Sep 17 00:00:00 2001
+From: Javier Pello <devel@otheo.eu>
+Date: Sat, 2 Sep 2023 17:10:39 +0200
+Subject: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
+
+From: Javier Pello <devel@otheo.eu>
+
+commit b7599d241778d0b10cdf7a5c755aa7db9b83250c upstream.
+
+There is an assertion in ggtt_reserve_guc_top that the global GTT
+is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit
+platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc
+("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON
+is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the
+subsequent reservation fails and the driver fails to initialise
+the device:
+
+i915 0000:00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC
+i915 0000:00:02.0: Device initialization failed (-28)
+i915 0000:00:02.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
+i915: probe of 0000:00:02.0 failed with error -28
+
+Make the reservation at the top of the available space, whatever
+that is, instead of assuming that the top will be GUC_GGTT_TOP.
+
+Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT")
+Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080
+Signed-off-by: Javier Pello <devel@otheo.eu>
+Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
+Cc: Fernando Pacheco <fernando.pacheco@intel.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
+Cc: intel-gfx@lists.freedesktop.org
+Cc: stable@vger.kernel.org # v5.3+
+Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230902171039.2229126186d697dbcf62d6d8@otheo.eu
+(cherry picked from commit 0f3fa942d91165c2702577e9274d2ee1c7212afc)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 +++++++++++++++++------
+ 1 file changed, 17 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
++++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
+@@ -500,20 +500,31 @@ void intel_ggtt_unbind_vma(struct i915_a
+ vm->clear_range(vm, vma_res->start, vma_res->vma_size);
+ }
+
++/*
++ * Reserve the top of the GuC address space for firmware images. Addresses
++ * beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC,
++ * which makes for a suitable range to hold GuC/HuC firmware images if the
++ * size of the GGTT is 4G. However, on a 32-bit platform the size of the GGTT
++ * is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a chunk
++ * of the same size anyway, which is far more than needed, to keep the logic
++ * in uc_fw_ggtt_offset() simple.
++ */
++#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP)
++
+ static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
+ {
+- u64 size;
++ u64 offset;
+ int ret;
+
+ if (!intel_uc_uses_guc(&ggtt->vm.gt->uc))
+ return 0;
+
+- GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP);
+- size = ggtt->vm.total - GUC_GGTT_TOP;
++ GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE);
++ offset = ggtt->vm.total - GUC_TOP_RESERVE_SIZE;
+
+- ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size,
+- GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE,
+- PIN_NOEVICT);
++ ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw,
++ GUC_TOP_RESERVE_SIZE, offset,
++ I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
+ if (ret)
+ drm_dbg(&ggtt->vm.i915->drm,
+ "Failed to reserve top of GGTT for GuC\n");
--- /dev/null
+From 099f0af9d98231bb74956ce92508e87cbcb896be Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Thu, 14 Sep 2023 16:10:15 +0300
+Subject: drm/meson: fix memory leak on ->hpd_notify callback
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
+
+The EDID returned by drm_bridge_get_edid() needs to be freed.
+
+Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR")
+Cc: Neil Armstrong <narmstrong@baylibre.com>
+Cc: Sam Ravnborg <sam@ravnborg.org>
+Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: Neil Armstrong <neil.armstrong@linaro.org>
+Cc: Kevin Hilman <khilman@baylibre.com>
+Cc: Jerome Brunet <jbrunet@baylibre.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-amlogic@lists.infradead.org
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: stable@vger.kernel.org # v5.17+
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230914131015.2472029-1-jani.nikula@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/meson/meson_encoder_hdmi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
++++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+@@ -332,6 +332,8 @@ static void meson_encoder_hdmi_hpd_notif
+ return;
+
+ cec_notifier_set_phys_addr_from_edid(encoder_hdmi->cec_notifier, edid);
++
++ kfree(edid);
+ } else
+ cec_notifier_phys_addr_invalidate(encoder_hdmi->cec_notifier);
+ }
--- /dev/null
+From 2ba157983974ae1b6aaef7d4953812020d6f1eb5 Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Mon, 11 Sep 2023 15:03:24 +0200
+Subject: drm/tests: Fix incorrect argument in drm_test_mm_insert_range
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit 2ba157983974ae1b6aaef7d4953812020d6f1eb5 upstream.
+
+While drm_mm test was converted form igt selftest to kunit, unexpected
+value of "end" argument equal "start" was introduced to one of calls to a
+function that executes the drm_test_mm_insert_range for specific start/end
+pair of arguments. As a consequence, DRM_MM_BUG_ON(end <= start) is
+triggered. Fix it by restoring the original value.
+
+Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit")
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Cc: "MaÃra Canal" <mairacanal@riseup.net>
+Cc: Arthur Grillo <arthurgrillo@riseup.net>
+Cc: Javier Martinez Canillas <javierm@redhat.com>
+Cc: Daniel Latypov <dlatypov@google.com>
+Cc: stable@vger.kernel.org # v6.1+
+Reviewed-by: MaÃra Canal <mairacanal@riseup.net>
+Signed-off-by: MaÃra Canal <mairacanal@riseup.net>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230911130323.7037-2-janusz.krzysztofik@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/tests/drm_mm_test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/tests/drm_mm_test.c b/drivers/gpu/drm/tests/drm_mm_test.c
+index 186b28dc7038..05d5e7af6d25 100644
+--- a/drivers/gpu/drm/tests/drm_mm_test.c
++++ b/drivers/gpu/drm/tests/drm_mm_test.c
+@@ -939,7 +939,7 @@ static void drm_test_mm_insert_range(struct kunit *test)
+ KUNIT_ASSERT_FALSE(test, __drm_test_mm_insert_range(test, count, size, 0, max - 1));
+ KUNIT_ASSERT_FALSE(test, __drm_test_mm_insert_range(test, count, size, 0, max / 2));
+ KUNIT_ASSERT_FALSE(test, __drm_test_mm_insert_range(test, count, size,
+- max / 2, max / 2));
++ max / 2, max));
+ KUNIT_ASSERT_FALSE(test, __drm_test_mm_insert_range(test, count, size,
+ max / 4 + 1, 3 * max / 4 - 1));
+
+--
+2.42.0
+
--- /dev/null
+From 7c3151585730b7095287be8162b846d31e6eee61 Mon Sep 17 00:00:00 2001
+From: Greg Ungerer <gerg@kernel.org>
+Date: Thu, 7 Sep 2023 11:18:08 +1000
+Subject: fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
+
+From: Greg Ungerer <gerg@kernel.org>
+
+commit 7c3151585730b7095287be8162b846d31e6eee61 upstream.
+
+The elf-fdpic loader hard sets the process personality to either
+PER_LINUX_FDPIC for true elf-fdpic binaries or to PER_LINUX for normal ELF
+binaries (in this case they would be constant displacement compiled with
+-pie for example). The problem with that is that it will lose any other
+bits that may be in the ELF header personality (such as the "bug
+emulation" bits).
+
+On the ARM architecture the ADDR_LIMIT_32BIT flag is used to signify a
+normal 32bit binary - as opposed to a legacy 26bit address binary. This
+matters since start_thread() will set the ARM CPSR register as required
+based on this flag. If the elf-fdpic loader loses this bit the process
+will be mis-configured and crash out pretty quickly.
+
+Modify elf-fdpic loader personality setting so that it preserves the upper
+three bytes by using the SET_PERSONALITY macro to set it. This macro in
+the generic case sets PER_LINUX and preserves the upper bytes.
+Architectures can override this for their specific use case, and ARM does
+exactly this.
+
+The problem shows up quite easily running under qemu using the ARM
+architecture, but not necessarily on all types of real ARM hardware. If
+the underlying ARM processor does not support the legacy 26-bit addressing
+mode then everything will work as expected.
+
+Link: https://lkml.kernel.org/r/20230907011808.2985083-1-gerg@kernel.org
+Fixes: 1bde925d23547 ("fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries")
+Signed-off-by: Greg Ungerer <gerg@kernel.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Greg Ungerer <gerg@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_elf_fdpic.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/binfmt_elf_fdpic.c
++++ b/fs/binfmt_elf_fdpic.c
+@@ -345,10 +345,9 @@ static int load_elf_fdpic_binary(struct
+ /* there's now no turning back... the old userspace image is dead,
+ * defunct, deceased, etc.
+ */
++ SET_PERSONALITY(exec_params.hdr);
+ if (elf_check_fdpic(&exec_params.hdr))
+- set_personality(PER_LINUX_FDPIC);
+- else
+- set_personality(PER_LINUX);
++ current->personality |= PER_LINUX_FDPIC;
+ if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
+ current->personality |= READ_IMPLIES_EXEC;
+
--- /dev/null
+From e6e43b8aa7cd3c3af686caf0c2e11819a886d705 Mon Sep 17 00:00:00 2001
+From: Quang Le <quanglex97@gmail.com>
+Date: Fri, 29 Sep 2023 00:44:13 +0700
+Subject: fs/smb/client: Reset password pointer to NULL
+
+From: Quang Le <quanglex97@gmail.com>
+
+commit e6e43b8aa7cd3c3af686caf0c2e11819a886d705 upstream.
+
+Forget to reset ctx->password to NULL will lead to bug like double free
+
+Cc: stable@vger.kernel.org
+Cc: Willy Tarreau <w@1wt.eu>
+Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Quang Le <quanglex97@gmail.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/fs_context.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/smb/client/fs_context.c
++++ b/fs/smb/client/fs_context.c
+@@ -1487,6 +1487,7 @@ static int smb3_fs_context_parse_param(s
+
+ cifs_parse_mount_err:
+ kfree_sensitive(ctx->password);
++ ctx->password = NULL;
+ return -EINVAL;
+ }
+
--- /dev/null
+From 41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Thu, 20 Jul 2023 17:46:54 +0000
+Subject: media: uvcvideo: Fix OOB read
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb upstream.
+
+If the index provided by the user is bigger than the mask size, we might do
+an out of bound read.
+
+CC: stable@kernel.org
+Fixes: 40140eda661e ("media: uvcvideo: Implement mask for V4L2_CTRL_TYPE_MENU")
+Reported-by: Zubin Mithra <zsm@chromium.org>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_ctrl.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/usb/uvc/uvc_ctrl.c
++++ b/drivers/media/usb/uvc/uvc_ctrl.c
+@@ -1347,6 +1347,9 @@ int uvc_query_v4l2_menu(struct uvc_video
+ query_menu->id = id;
+ query_menu->index = index;
+
++ if (index >= BITS_PER_TYPE(mapping->menu_mask))
++ return -EINVAL;
++
+ ret = mutex_lock_interruptible(&chain->ctrl_mutex);
+ if (ret < 0)
+ return -ERESTARTSYS;
--- /dev/null
+From 45120b15743fa7c0aa53d5db6dfb4c8f87be4abd Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Mon, 25 Sep 2023 15:20:59 +0800
+Subject: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+commit 45120b15743fa7c0aa53d5db6dfb4c8f87be4abd upstream.
+
+When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
+and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
+
+Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
+variables"), the damon_destroy_ctx() is removed, but still call
+damon_new_target() and damon_new_region(), the damon_region which is
+allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
+which is allocated by kmalloc in damon_new_target() are not freed. And
+the damon_region which is allocated in damon_new_region() in
+damon_set_regions() is also not freed.
+
+So use damon_destroy_target to free all the damon_regions and damon_target.
+
+ unreferenced object 0xffff888107c9a940 (size 64):
+ comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
+ 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
+ backtrace:
+ [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
+ [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
+ [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
+ [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff8881079cc740 (size 56):
+ comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
+ hex dump (first 32 bytes):
+ 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
+ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
+ backtrace:
+ [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
+ [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
+ [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff888107c9ac40 (size 64):
+ comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
+ a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
+ backtrace:
+ [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
+ [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
+ [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
+ [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff8881079ccc80 (size 56):
+ comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
+ hex dump (first 32 bytes):
+ 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
+ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
+ backtrace:
+ [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
+ [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
+ [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff888107c9af40 (size 64):
+ comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
+ 20 a2 76 07 81 88 ff ff b8 a6 76 07 81 88 ff ff .v.......v.....
+ backtrace:
+ [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
+ [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
+ [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
+ [<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff88810776a200 (size 56):
+ comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
+ hex dump (first 32 bytes):
+ 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
+ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
+ backtrace:
+ [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
+ [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
+ [<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff88810776a740 (size 56):
+ comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.025s)
+ hex dump (first 32 bytes):
+ 3d 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 00 =.......?.......
+ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
+ backtrace:
+ [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
+ [<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
+ [<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
+ [<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff888108038240 (size 64):
+ comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 03 00 00 00 6b 6b 6b 6b ............kkkk
+ 48 ad 76 07 81 88 ff ff 98 ae 76 07 81 88 ff ff H.v.......v.....
+ backtrace:
+ [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
+ [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
+ [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
+ [<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+ unreferenced object 0xffff88810776ad28 (size 56):
+ comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
+ hex dump (first 32 bytes):
+ 05 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................
+ 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
+ backtrace:
+ [<ffffffff819bc492>] damon_new_region+0x22/0x1c0
+ [<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
+ [<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
+ [<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
+ [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
+ [<ffffffff81237cf6>] kthread+0x2b6/0x380
+ [<ffffffff81097add>] ret_from_fork+0x2d/0x70
+ [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
+
+Link: https://lkml.kernel.org/r/20230925072100.3725620-1-ruanjinjie@huawei.com
+Fixes: 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary variables")
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Reviewed-by: SeongJae Park <sj@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/damon/vaddr-test.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/damon/vaddr-test.h
++++ b/mm/damon/vaddr-test.h
+@@ -140,6 +140,8 @@ static void damon_do_test_apply_three_re
+ KUNIT_EXPECT_EQ(test, r->ar.start, expected[i * 2]);
+ KUNIT_EXPECT_EQ(test, r->ar.end, expected[i * 2 + 1]);
+ }
++
++ damon_destroy_target(t);
+ }
+
+ /*
--- /dev/null
+From 9ea9cb00a82b53ec39630eac718776d37e41b35a Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Thu, 14 Sep 2023 11:21:39 -0400
+Subject: mm: memcontrol: fix GFP_NOFS recursion in memory.high enforcement
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit 9ea9cb00a82b53ec39630eac718776d37e41b35a upstream.
+
+Breno and Josef report a deadlock scenario from cgroup reclaim
+re-entering the filesystem:
+
+[ 361.546690] ======================================================
+[ 361.559210] WARNING: possible circular locking dependency detected
+[ 361.571703] 6.5.0-0_fbk700_debug_rc0_kbuilder_13159_gbf787a128001 #1 Tainted: G S E
+[ 361.589704] ------------------------------------------------------
+[ 361.602277] find/9315 is trying to acquire lock:
+[ 361.611625] ffff88837ba140c0 (&delayed_node->mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0x68/0x4f0
+[ 361.631437]
+[ 361.631437] but task is already holding lock:
+[ 361.643243] ffff8881765b8678 (btrfs-tree-01){++++}-{4:4}, at: btrfs_tree_read_lock+0x1e/0x40
+
+[ 362.904457] mutex_lock_nested+0x1c/0x30
+[ 362.912414] __btrfs_release_delayed_node+0x68/0x4f0
+[ 362.922460] btrfs_evict_inode+0x301/0x770
+[ 362.982726] evict+0x17c/0x380
+[ 362.988944] prune_icache_sb+0x100/0x1d0
+[ 363.005559] super_cache_scan+0x1f8/0x260
+[ 363.013695] do_shrink_slab+0x2a2/0x540
+[ 363.021489] shrink_slab_memcg+0x237/0x3d0
+[ 363.050606] shrink_slab+0xa7/0x240
+[ 363.083382] shrink_node_memcgs+0x262/0x3b0
+[ 363.091870] shrink_node+0x1a4/0x720
+[ 363.099150] shrink_zones+0x1f6/0x5d0
+[ 363.148798] do_try_to_free_pages+0x19b/0x5e0
+[ 363.157633] try_to_free_mem_cgroup_pages+0x266/0x370
+[ 363.190575] reclaim_high+0x16f/0x1f0
+[ 363.208409] mem_cgroup_handle_over_high+0x10b/0x270
+[ 363.246678] try_charge_memcg+0xaf2/0xc70
+[ 363.304151] charge_memcg+0xf0/0x350
+[ 363.320070] __mem_cgroup_charge+0x28/0x40
+[ 363.328371] __filemap_add_folio+0x870/0xd50
+[ 363.371303] filemap_add_folio+0xdd/0x310
+[ 363.399696] __filemap_get_folio+0x2fc/0x7d0
+[ 363.419086] pagecache_get_page+0xe/0x30
+[ 363.427048] alloc_extent_buffer+0x1cd/0x6a0
+[ 363.435704] read_tree_block+0x43/0xc0
+[ 363.443316] read_block_for_search+0x361/0x510
+[ 363.466690] btrfs_search_slot+0xc8c/0x1520
+
+This is caused by the mem_cgroup_handle_over_high() not respecting the
+gfp_mask of the allocation context. We used to only call this function on
+resume to userspace, where no locks were held. But c9afe31ec443 ("memcg:
+synchronously enforce memory.high for large overcharges") added a call
+from the allocation context without considering the gfp.
+
+Link: https://lkml.kernel.org/r/20230914152139.100822-1-hannes@cmpxchg.org
+Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges")
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Reported-by: Breno Leitao <leitao@debian.org>
+Reported-by: Josef Bacik <josef@toxicpanda.com>
+Acked-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: Muchun Song <songmuchun@bytedance.com>
+Cc: <stable@vger.kernel.org> [5.17+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/memcontrol.h | 4 ++--
+ include/linux/resume_user_mode.h | 2 +-
+ mm/memcontrol.c | 6 +++---
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/include/linux/memcontrol.h
++++ b/include/linux/memcontrol.h
+@@ -902,7 +902,7 @@ unsigned long mem_cgroup_get_zone_lru_si
+ return READ_ONCE(mz->lru_zone_size[zone_idx][lru]);
+ }
+
+-void mem_cgroup_handle_over_high(void);
++void mem_cgroup_handle_over_high(gfp_t gfp_mask);
+
+ unsigned long mem_cgroup_get_max(struct mem_cgroup *memcg);
+
+@@ -1437,7 +1437,7 @@ static inline void mem_cgroup_unlock_pag
+ rcu_read_unlock();
+ }
+
+-static inline void mem_cgroup_handle_over_high(void)
++static inline void mem_cgroup_handle_over_high(gfp_t gfp_mask)
+ {
+ }
+
+--- a/include/linux/resume_user_mode.h
++++ b/include/linux/resume_user_mode.h
+@@ -55,7 +55,7 @@ static inline void resume_user_mode_work
+ }
+ #endif
+
+- mem_cgroup_handle_over_high();
++ mem_cgroup_handle_over_high(GFP_KERNEL);
+ blkcg_maybe_throttle_current();
+
+ rseq_handle_notify_resume(NULL, regs);
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -2545,7 +2545,7 @@ static unsigned long calculate_high_dela
+ * Scheduled by try_charge() to be executed from the userland return path
+ * and reclaims memory over the high limit.
+ */
+-void mem_cgroup_handle_over_high(void)
++void mem_cgroup_handle_over_high(gfp_t gfp_mask)
+ {
+ unsigned long penalty_jiffies;
+ unsigned long pflags;
+@@ -2573,7 +2573,7 @@ retry_reclaim:
+ */
+ nr_reclaimed = reclaim_high(memcg,
+ in_retry ? SWAP_CLUSTER_MAX : nr_pages,
+- GFP_KERNEL);
++ gfp_mask);
+
+ /*
+ * memory.high is breached and reclaim is unable to keep up. Throttle
+@@ -2809,7 +2809,7 @@ done_restock:
+ if (current->memcg_nr_pages_over_high > MEMCG_CHARGE_BATCH &&
+ !(current->flags & PF_MEMALLOC) &&
+ gfpflags_allow_blocking(gfp_mask)) {
+- mem_cgroup_handle_over_high();
++ mem_cgroup_handle_over_high(gfp_mask);
+ }
+ return 0;
+ }
--- /dev/null
+From 46a9ea6681907a3be6b6b0d43776dccc62cad6cf Mon Sep 17 00:00:00 2001
+From: Rafael Aquini <aquini@redhat.com>
+Date: Fri, 8 Sep 2023 19:06:49 -0400
+Subject: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()
+
+From: Rafael Aquini <aquini@redhat.com>
+
+commit 46a9ea6681907a3be6b6b0d43776dccc62cad6cf upstream.
+
+After the commit in Fixes:, if a module that created a slab cache does not
+release all of its allocated objects before destroying the cache (at rmmod
+time), we might end up releasing the kmem_cache object without removing it
+from the slab_caches list thus corrupting the list as kmem_cache_destroy()
+ignores the return value from shutdown_cache(), which in turn never removes
+the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails
+to release all of the cache's slabs.
+
+This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y
+as after that ill release the system will immediately trip on list_add,
+or list_del, assertions similar to the one shown below as soon as another
+kmem_cache gets created, or destroyed:
+
+ [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268)
+ [ 1041.219165] ------------[ cut here ]------------
+ [ 1041.221517] kernel BUG at lib/list_debug.c:62!
+ [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI
+ [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15
+ [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023
+ [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0
+
+Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y,
+is to set slub_debug to poison the released objects and then just run
+cat /proc/slabinfo after removing the module that leaks slab objects,
+in which case the kernel will panic:
+
+ [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI
+ [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15
+ [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023
+ [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0
+
+This patch fixes this issue by properly checking shutdown_cache()'s
+return value before taking the kmem_cache_release() branch.
+
+Fixes: 0495e337b703 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock")
+Signed-off-by: Rafael Aquini <aquini@redhat.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Waiman Long <longman@redhat.com>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slab_common.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/mm/slab_common.c
++++ b/mm/slab_common.c
+@@ -474,7 +474,7 @@ void slab_kmem_cache_release(struct kmem
+
+ void kmem_cache_destroy(struct kmem_cache *s)
+ {
+- int refcnt;
++ int err = -EBUSY;
+ bool rcu_set;
+
+ if (unlikely(!s) || !kasan_check_byte(s))
+@@ -485,17 +485,17 @@ void kmem_cache_destroy(struct kmem_cach
+
+ rcu_set = s->flags & SLAB_TYPESAFE_BY_RCU;
+
+- refcnt = --s->refcount;
+- if (refcnt)
++ s->refcount--;
++ if (s->refcount)
+ goto out_unlock;
+
+- WARN(shutdown_cache(s),
+- "%s %s: Slab cache still has objects when called from %pS",
++ err = shutdown_cache(s);
++ WARN(err, "%s %s: Slab cache still has objects when called from %pS",
+ __func__, s->name, (void *)_RET_IP_);
+ out_unlock:
+ mutex_unlock(&slab_mutex);
+ cpus_read_unlock();
+- if (!refcnt && !rcu_set)
++ if (!err && !rcu_set)
+ kmem_cache_release(s);
+ }
+ EXPORT_SYMBOL(kmem_cache_destroy);
--- /dev/null
+From e0b65f9b81fef180cf5f103adecbe5505c961153 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Wed, 13 Sep 2023 08:26:47 +0300
+Subject: net: thunderbolt: Fix TCPv6 GSO checksum calculation
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit e0b65f9b81fef180cf5f103adecbe5505c961153 upstream.
+
+Alex reported that running ssh over IPv6 does not work with
+Thunderbolt/USB4 networking driver. The reason for that is that driver
+should call skb_is_gso() before calling skb_is_gso_v6(), and it should
+not return false after calculates the checksum successfully. This probably
+was a copy paste error from the original driver where it was done properly.
+
+Reported-by: Alex Balcanquall <alex@alexbal.com>
+Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Jiri Pirko <jiri@nvidia.com>
+Reviewed-by: Jiri Pirko <jiri@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/thunderbolt.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/thunderbolt.c
++++ b/drivers/net/thunderbolt.c
+@@ -1005,12 +1005,11 @@ static bool tbnet_xmit_csum_and_map(stru
+ *tucso = ~csum_tcpudp_magic(ip_hdr(skb)->saddr,
+ ip_hdr(skb)->daddr, 0,
+ ip_hdr(skb)->protocol, 0);
+- } else if (skb_is_gso_v6(skb)) {
++ } else if (skb_is_gso(skb) && skb_is_gso_v6(skb)) {
+ tucso = dest + ((void *)&(tcp_hdr(skb)->check) - data);
+ *tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr, 0,
+ IPPROTO_TCP, 0);
+- return false;
+ } else if (protocol == htons(ETH_P_IPV6)) {
+ tucso = dest + skb_checksum_start_offset(skb) + skb->csum_offset;
+ *tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
--- /dev/null
+From dc77721ea4aa1e8937e2436f230b5a69065cc508 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Tue, 13 Jun 2023 23:31:50 +0200
+Subject: power: supply: ab8500: Set typing and props
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit dc77721ea4aa1e8937e2436f230b5a69065cc508 upstream.
+
+I had the following weird phenomena on a mobile phone: while
+the capacity in /sys/class/power_supply/ab8500_fg/capacity
+would reflect the actual charge and capacity of the battery,
+only 1/3 of the value was shown on the battery status
+indicator and warnings for low battery appeared.
+
+It turns out that UPower, the Freedesktop power daemon,
+will average all the power supplies of type "battery" in
+/sys/class/power_supply/* if there is more than one battery.
+
+For the AB8500, there was "battery" ab8500_fg, ab8500_btemp
+and ab8500_chargalg. The latter two don't know anything
+about the battery, and should not be considered. They were
+however averaged and with the capacity of 0.
+
+Flag ab8500_btemp and ab8500_chargalg with type "unknown"
+so they are not averaged as batteries.
+
+Remove the technology prop from ab8500_btemp as well, all
+it does is snoop in on knowledge from another supply.
+
+After this the battery indicator shows the right value.
+
+Cc: Stefan Hansson <newbyte@disroot.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/ab8500_btemp.c | 9 +--------
+ drivers/power/supply/ab8500_chargalg.c | 2 +-
+ 2 files changed, 2 insertions(+), 9 deletions(-)
+
+--- a/drivers/power/supply/ab8500_btemp.c
++++ b/drivers/power/supply/ab8500_btemp.c
+@@ -115,7 +115,6 @@ struct ab8500_btemp {
+ static enum power_supply_property ab8500_btemp_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+- POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_TEMP,
+ };
+
+@@ -532,12 +531,6 @@ static int ab8500_btemp_get_property(str
+ else
+ val->intval = 1;
+ break;
+- case POWER_SUPPLY_PROP_TECHNOLOGY:
+- if (di->bm->bi)
+- val->intval = di->bm->bi->technology;
+- else
+- val->intval = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
+- break;
+ case POWER_SUPPLY_PROP_TEMP:
+ val->intval = ab8500_btemp_get_temp(di);
+ break;
+@@ -662,7 +655,7 @@ static char *supply_interface[] = {
+
+ static const struct power_supply_desc ab8500_btemp_desc = {
+ .name = "ab8500_btemp",
+- .type = POWER_SUPPLY_TYPE_BATTERY,
++ .type = POWER_SUPPLY_TYPE_UNKNOWN,
+ .properties = ab8500_btemp_props,
+ .num_properties = ARRAY_SIZE(ab8500_btemp_props),
+ .get_property = ab8500_btemp_get_property,
+--- a/drivers/power/supply/ab8500_chargalg.c
++++ b/drivers/power/supply/ab8500_chargalg.c
+@@ -1720,7 +1720,7 @@ static char *supply_interface[] = {
+
+ static const struct power_supply_desc ab8500_chargalg_desc = {
+ .name = "ab8500_chargalg",
+- .type = POWER_SUPPLY_TYPE_BATTERY,
++ .type = POWER_SUPPLY_TYPE_UNKNOWN,
+ .properties = ab8500_chargalg_props,
+ .num_properties = ARRAY_SIZE(ab8500_chargalg_props),
+ .get_property = ab8500_chargalg_get_property,
--- /dev/null
+From cbcdfbf5a6cd66e47e5ee5d49c4c5a27a07ba082 Mon Sep 17 00:00:00 2001
+From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
+Date: Mon, 12 Jun 2023 16:36:52 +0200
+Subject: power: supply: rk817: Add missing module alias
+
+From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
+
+commit cbcdfbf5a6cd66e47e5ee5d49c4c5a27a07ba082 upstream.
+
+Similar to the rk817 codec alias that was missing, the rk817 charger
+driver is missing a module alias as well. This absence prevents the
+driver from autoprobing on OF systems when it is built as a module.
+
+Add the right MODULE_ALIAS to fix this.
+
+Fixes: 11cb8da0189b ("power: supply: Add charger driver for Rockchip RK817")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
+Reviewed-by: Chris Morgan <macromorgan@hotmail.com>
+Link: https://lore.kernel.org/r/20230612143651.959646-2-frattaroli.nicolas@gmail.com
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/rk817_charger.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/power/supply/rk817_charger.c
++++ b/drivers/power/supply/rk817_charger.c
+@@ -1233,3 +1233,4 @@ MODULE_DESCRIPTION("Battery power supply
+ MODULE_AUTHOR("Maya Matuszczyk <maccraft123mc@gmail.com>");
+ MODULE_AUTHOR("Chris Morgan <macromorgan@hotmail.com>");
+ MODULE_LICENSE("GPL");
++MODULE_ALIAS("platform:rk817-charger");
--- /dev/null
+From a275ab62606bcd894ddff09460f7d253828313dc Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Sun, 17 Sep 2023 19:26:46 -0400
+Subject: Revert "SUNRPC dont update timeout value on connection reset"
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+commit a275ab62606bcd894ddff09460f7d253828313dc upstream.
+
+This reverts commit 88428cc4ae7abcc879295fbb19373dd76aad2bdd.
+
+The problem this commit is intended to fix was comprehensively fixed
+in commit 7de62bc09fe6 ("SUNRPC dont update timeout value on connection
+reset").
+Since then, this commit has been preventing the correct timeout of soft
+mounted requests.
+
+Cc: stable@vger.kernel.org # 5.9.x: 09252177d5f9: SUNRPC: Handle major timeout in xprt_adjust_timeout()
+Cc: stable@vger.kernel.org # 5.9.x: 7de62bc09fe6: SUNRPC dont update timeout value on connection reset
+Cc: stable@vger.kernel.org # 5.9.x
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sunrpc/clnt.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/sunrpc/clnt.c
++++ b/net/sunrpc/clnt.c
+@@ -2462,8 +2462,7 @@ call_status(struct rpc_task *task)
+ goto out_exit;
+ }
+ task->tk_action = call_encode;
+- if (status != -ECONNRESET && status != -ECONNABORTED)
+- rpc_check_timeout(task);
++ rpc_check_timeout(task);
+ return;
+ out_exit:
+ rpc_call_rpcerror(task, status);
--- /dev/null
+From 1e0cb399c7653462d9dadf8ab9425337c355d358 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Fri, 29 Sep 2023 18:01:13 -0400
+Subject: ring-buffer: Update "shortest_full" in polling
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 1e0cb399c7653462d9dadf8ab9425337c355d358 upstream.
+
+It was discovered that the ring buffer polling was incorrectly stating
+that read would not block, but that's because polling did not take into
+account that reads will block if the "buffer-percent" was set. Instead,
+the ring buffer polling would say reads would not block if there was any
+data in the ring buffer. This was incorrect behavior from a user space
+point of view. This was fixed by commit 42fb0a1e84ff by having the polling
+code check if the ring buffer had more data than what the user specified
+"buffer percent" had.
+
+The problem now is that the polling code did not register itself to the
+writer that it wanted to wait for a specific "full" value of the ring
+buffer. The result was that the writer would wake the polling waiter
+whenever there was a new event. The polling waiter would then wake up, see
+that there's not enough data in the ring buffer to notify user space and
+then go back to sleep. The next event would wake it up again.
+
+Before the polling fix was added, the code would wake up around 100 times
+for a hackbench 30 benchmark. After the "fix", due to the constant waking
+of the writer, it would wake up over 11,0000 times! It would never leave
+the kernel, so the user space behavior was still "correct", but this
+definitely is not the desired effect.
+
+To fix this, have the polling code add what it's waiting for to the
+"shortest_full" variable, to tell the writer not to wake it up if the
+buffer is not as full as it expects to be.
+
+Note, after this fix, it appears that the waiter is now woken up around 2x
+the times it was before (~200). This is a tremendous improvement from the
+11,000 times, but I will need to spend some time to see why polling is
+more aggressive in its wakeups than the read blocking code.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230929180113.01c2cae3@rorschach.local.home
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Fixes: 42fb0a1e84ff ("tracing/ring-buffer: Have polling block on watermark")
+Reported-by: Julia Lawall <julia.lawall@inria.fr>
+Tested-by: Julia Lawall <julia.lawall@inria.fr>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1142,6 +1142,9 @@ __poll_t ring_buffer_poll_wait(struct tr
+ if (full) {
+ poll_wait(filp, &work->full_waiters, poll_table);
+ work->full_waiters_pending = true;
++ if (!cpu_buffer->shortest_full ||
++ cpu_buffer->shortest_full > full)
++ cpu_buffer->shortest_full = full;
+ } else {
+ poll_wait(filp, &work->waiters, poll_table);
+ work->waiters_pending = true;
kernel-sched-modify-initial-boot-task-idle-setup.patch
sched-rt-fix-live-lock-between-select_fallback_rq-and-rt-push.patch
netfilter-nf_tables-fix-kdoc-warnings-after-gc-rework.patch
+revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch
+timers-tag-hr-timer-softirq-as-hotplug-safe.patch
+drm-tests-fix-incorrect-argument-in-drm_test_mm_insert_range.patch
+arm64-defconfig-remove-config_common_clk_npcm8xx-y.patch
+mm-damon-vaddr-test-fix-memory-leak-in-damon_do_test_apply_three_regions.patch
+mm-slab_common-fix-slab_caches-list-corruption-after-kmem_cache_destroy.patch
+mm-memcontrol-fix-gfp_nofs-recursion-in-memory.high-enforcement.patch
+ring-buffer-update-shortest_full-in-polling.patch
+btrfs-properly-report-0-avail-for-very-full-file-systems.patch
+media-uvcvideo-fix-oob-read.patch
+bpf-add-override-check-to-kprobe-multi-link-attach.patch
+bpf-fix-btf_id-symbol-generation-collision.patch
+bpf-fix-btf_id-symbol-generation-collision-in-tools.patch
+net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch
+fs-smb-client-reset-password-pointer-to-null.patch
+ata-libata-core-fix-ata_port_request_pm-locking.patch
+ata-libata-core-fix-port-and-device-removal.patch
+ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch
+ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch
+drm-i915-gt-fix-reservation-address-in-ggtt_reserve_guc_top.patch
+power-supply-rk817-add-missing-module-alias.patch
+power-supply-ab8500-set-typing-and-props.patch
+fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch
+drm-amdkfd-use-gpu_offset-for-user-queue-s-wptr.patch
+drm-meson-fix-memory-leak-on-hpd_notify-callback.patch
--- /dev/null
+From 1a6a464774947920dcedcf7409be62495c7cedd0 Mon Sep 17 00:00:00 2001
+From: Frederic Weisbecker <frederic@kernel.org>
+Date: Tue, 12 Sep 2023 12:44:06 +0200
+Subject: timers: Tag (hr)timer softirq as hotplug safe
+
+From: Frederic Weisbecker <frederic@kernel.org>
+
+commit 1a6a464774947920dcedcf7409be62495c7cedd0 upstream.
+
+Specific stress involving frequent CPU-hotplug operations, such as
+running rcutorture for example, may trigger the following message:
+
+ NOHZ tick-stop error: local softirq work is pending, handler #02!!!"
+
+This happens in the CPU-down hotplug process, after
+CPUHP_AP_SMPBOOT_THREADS whose teardown callback parks ksoftirqd, and
+before the target CPU shuts down through CPUHP_AP_IDLE_DEAD. In this
+fragile intermediate state, softirqs waiting for threaded handling may be
+forever ignored and eventually reported by the idle task as in the above
+example.
+
+However some vectors are known to be safe as long as the corresponding
+subsystems have teardown callbacks handling the migration of their
+events. The above error message reports pending timers softirq although
+this vector can be considered as hotplug safe because the
+CPUHP_TIMERS_PREPARE teardown callback performs the necessary migration
+of timers after the death of the CPU. Hrtimers also have a similar
+hotplug handling.
+
+Therefore this error message, as far as (hr-)timers are concerned, can
+be considered spurious and the relevant softirq vectors can be marked as
+hotplug safe.
+
+Fixes: 0345691b24c0 ("tick/rcu: Stop allowing RCU_SOFTIRQ in idle")
+Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230912104406.312185-6-frederic@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/interrupt.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/include/linux/interrupt.h
++++ b/include/linux/interrupt.h
+@@ -569,8 +569,12 @@ enum
+ * 2) rcu_report_dead() reports the final quiescent states.
+ *
+ * _ IRQ_POLL: irq_poll_cpu_dead() migrates the queue
++ *
++ * _ (HR)TIMER_SOFTIRQ: (hr)timers_dead_cpu() migrates the queue
+ */
+-#define SOFTIRQ_HOTPLUG_SAFE_MASK (BIT(RCU_SOFTIRQ) | BIT(IRQ_POLL_SOFTIRQ))
++#define SOFTIRQ_HOTPLUG_SAFE_MASK (BIT(TIMER_SOFTIRQ) | BIT(IRQ_POLL_SOFTIRQ) |\
++ BIT(HRTIMER_SOFTIRQ) | BIT(RCU_SOFTIRQ))
++
+
+ /* map softirq index to softirq name. update 'softirq_to_name' in
+ * kernel/softirq.c when adding a new softirq.
projects / thirdparty / kernel / stable-queue.git / commitdiff
