From: Greg Kroah-Hartman Date: Wed, 4 Oct 2023 17:04:09 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v6.5.6~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8fa89d88243d22215684d080bf9b00ee9978ca67;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: arm64-defconfig-remove-config_common_clk_npcm8xx-y.patch ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch ata-libata-core-fix-ata_port_request_pm-locking.patch ata-libata-core-fix-port-and-device-removal.patch ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch bpf-add-override-check-to-kprobe-multi-link-attach.patch bpf-fix-btf_id-symbol-generation-collision-in-tools.patch bpf-fix-btf_id-symbol-generation-collision.patch btrfs-properly-report-0-avail-for-very-full-file-systems.patch drm-amdkfd-use-gpu_offset-for-user-queue-s-wptr.patch drm-i915-gt-fix-reservation-address-in-ggtt_reserve_guc_top.patch drm-meson-fix-memory-leak-on-hpd_notify-callback.patch drm-tests-fix-incorrect-argument-in-drm_test_mm_insert_range.patch fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch fs-smb-client-reset-password-pointer-to-null.patch media-uvcvideo-fix-oob-read.patch mm-damon-vaddr-test-fix-memory-leak-in-damon_do_test_apply_three_regions.patch mm-memcontrol-fix-gfp_nofs-recursion-in-memory.high-enforcement.patch mm-slab_common-fix-slab_caches-list-corruption-after-kmem_cache_destroy.patch net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch power-supply-ab8500-set-typing-and-props.patch power-supply-rk817-add-missing-module-alias.patch revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch ring-buffer-update-shortest_full-in-polling.patch timers-tag-hr-timer-softirq-as-hotplug-safe.patch --- diff --git a/queue-6.1/arm64-defconfig-remove-config_common_clk_npcm8xx-y.patch b/queue-6.1/arm64-defconfig-remove-config_common_clk_npcm8xx-y.patch new file mode 100644 index 00000000000..d940f1d71c4 --- /dev/null +++ b/queue-6.1/arm64-defconfig-remove-config_common_clk_npcm8xx-y.patch @@ -0,0 +1,57 @@ +From 7d3e4e9d3bde9c8bd8914d47ddaa90e0d0ffbcab Mon Sep 17 00:00:00 2001 +From: Mikko Rapeli +Date: Thu, 21 Sep 2023 17:57:22 +0300 +Subject: arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y + +From: Mikko Rapeli + +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 +Cc: Will Deacon +Cc: Bjorn Andersson +Cc: Krzysztof Kozlowski +Cc: Konrad Dybcio +Cc: Neil Armstrong +Cc: Tomer Maimon +Cc: Bruce Ashfield +Cc: Jon Mason +Cc: Jon Mason +Cc: Ross Burton +Cc: Arnd Bergmann +Signed-off-by: Mikko Rapeli +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.1/ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch b/queue-6.1/ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch new file mode 100644 index 00000000000..2b6cfae484c --- /dev/null +++ b/queue-6.1/ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch @@ -0,0 +1,82 @@ +From 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +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 + +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 +Reviewed-by: Hannes Reinecke +Tested-by: Chia-Lin Kao (AceLan) +Tested-by: Geert Uytterhoeven +Reviewed-by: John Garry +Reviewed-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/ata-libata-core-fix-ata_port_request_pm-locking.patch b/queue-6.1/ata-libata-core-fix-ata_port_request_pm-locking.patch new file mode 100644 index 00000000000..798185b74fa --- /dev/null +++ b/queue-6.1/ata-libata-core-fix-ata_port_request_pm-locking.patch @@ -0,0 +1,75 @@ +From 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Mon, 4 Sep 2023 20:38:13 +0900 +Subject: ata: libata-core: Fix ata_port_request_pm() locking + +From: Damien Le Moal + +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 +Reviewed-by: Hannes Reinecke +Tested-by: Chia-Lin Kao (AceLan) +Reviewed-by: Niklas Cassel +Tested-by: Geert Uytterhoeven +Reviewed-by: Martin K. Petersen +Reviewed-by: Bart Van Assche +Signed-off-by: Greg Kroah-Hartman +--- + 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); +- } + } + + /* diff --git a/queue-6.1/ata-libata-core-fix-port-and-device-removal.patch b/queue-6.1/ata-libata-core-fix-port-and-device-removal.patch new file mode 100644 index 00000000000..ab6b4a649fb --- /dev/null +++ b/queue-6.1/ata-libata-core-fix-port-and-device-removal.patch @@ -0,0 +1,81 @@ +From 84d76529c650f887f1e18caee72d6f0589e1baf9 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Sat, 26 Aug 2023 13:07:36 +0900 +Subject: ata: libata-core: Fix port and device removal + +From: Damien Le Moal + +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 +Reviewed-by: Hannes Reinecke +Reviewed-by: Niklas Cassel +Tested-by: Chia-Lin Kao (AceLan) +Tested-by: Geert Uytterhoeven +Reviewed-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch b/queue-6.1/ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch new file mode 100644 index 00000000000..feb3ec8091d --- /dev/null +++ b/queue-6.1/ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch @@ -0,0 +1,50 @@ +From 753a4d531bc518633ea88ac0ed02b25a16823d51 Mon Sep 17 00:00:00 2001 +From: Matthias Schiffer +Date: Fri, 22 Sep 2023 22:55:16 +0200 +Subject: ata: libata-sata: increase PMP SRST timeout to 10s + +From: Matthias Schiffer + +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 +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.1/bpf-add-override-check-to-kprobe-multi-link-attach.patch b/queue-6.1/bpf-add-override-check-to-kprobe-multi-link-attach.patch new file mode 100644 index 00000000000..eda2449b0b1 --- /dev/null +++ b/queue-6.1/bpf-add-override-check-to-kprobe-multi-link-attach.patch @@ -0,0 +1,56 @@ +From 41bc46c12a8053a1b3279a379bd6b5e87b045b85 Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Thu, 7 Sep 2023 22:06:51 +0200 +Subject: bpf: Add override check to kprobe multi link attach + +From: Jiri Olsa + +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 +Signed-off-by: Andrii Nakryiko +Reviewed-by: Alan Maguire +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/bpf/20230907200652.926951-1-jolsa@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/bpf-fix-btf_id-symbol-generation-collision-in-tools.patch b/queue-6.1/bpf-fix-btf_id-symbol-generation-collision-in-tools.patch new file mode 100644 index 00000000000..3b967b0a10b --- /dev/null +++ b/queue-6.1/bpf-fix-btf_id-symbol-generation-collision-in-tools.patch @@ -0,0 +1,49 @@ +From c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 Mon Sep 17 00:00:00 2001 +From: Nick Desaulniers +Date: Fri, 15 Sep 2023 10:34:28 -0700 +Subject: bpf: Fix BTF_ID symbol generation collision in tools/ + +From: Nick Desaulniers + +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 :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 +Reported-by: Marcus Seyfarth +Closes: https://github.com/ClangBuiltLinux/linux/issues/1913 +Debugged-by: Nathan Chancellor +Co-developed-by: Jiri Olsa +Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/ +Signed-off-by: Nick Desaulniers +Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-2-263fc519c21f@google.com +Signed-off-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.1/bpf-fix-btf_id-symbol-generation-collision.patch b/queue-6.1/bpf-fix-btf_id-symbol-generation-collision.patch new file mode 100644 index 00000000000..30735566537 --- /dev/null +++ b/queue-6.1/bpf-fix-btf_id-symbol-generation-collision.patch @@ -0,0 +1,50 @@ +From 8f908db77782630c45ba29dac35c434b5ce0b730 Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Fri, 15 Sep 2023 10:34:27 -0700 +Subject: bpf: Fix BTF_ID symbol generation collision + +From: Jiri Olsa + +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 :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 +Reported-by: Marcus Seyfarth +Closes: https://github.com/ClangBuiltLinux/linux/issues/1913 +Debugged-by: Nathan Chancellor +Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/ +Signed-off-by: Jiri Olsa +Signed-off-by: Nick Desaulniers +Reviewed-by: Nathan Chancellor +Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-1-263fc519c21f@google.com +Signed-off-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.1/btrfs-properly-report-0-avail-for-very-full-file-systems.patch b/queue-6.1/btrfs-properly-report-0-avail-for-very-full-file-systems.patch new file mode 100644 index 00000000000..886eefffaed --- /dev/null +++ b/queue-6.1/btrfs-properly-report-0-avail-for-very-full-file-systems.patch @@ -0,0 +1,43 @@ +From 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Mon, 18 Sep 2023 10:34:51 -0400 +Subject: btrfs: properly report 0 avail for very full file systems + +From: Josef Bacik + +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 +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/drm-amdkfd-use-gpu_offset-for-user-queue-s-wptr.patch b/queue-6.1/drm-amdkfd-use-gpu_offset-for-user-queue-s-wptr.patch new file mode 100644 index 00000000000..46d73d2aa29 --- /dev/null +++ b/queue-6.1/drm-amdkfd-use-gpu_offset-for-user-queue-s-wptr.patch @@ -0,0 +1,35 @@ +From cc39f9ccb82426e576734b493e1777ea01b144a8 Mon Sep 17 00:00:00 2001 +From: YuBiao Wang +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 + +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 +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/drm-i915-gt-fix-reservation-address-in-ggtt_reserve_guc_top.patch b/queue-6.1/drm-i915-gt-fix-reservation-address-in-ggtt_reserve_guc_top.patch new file mode 100644 index 00000000000..408acc970da --- /dev/null +++ b/queue-6.1/drm-i915-gt-fix-reservation-address-in-ggtt_reserve_guc_top.patch @@ -0,0 +1,86 @@ +From b7599d241778d0b10cdf7a5c755aa7db9b83250c Mon Sep 17 00:00:00 2001 +From: Javier Pello +Date: Sat, 2 Sep 2023 17:10:39 +0200 +Subject: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top + +From: Javier Pello + +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 +Reviewed-by: Daniele Ceraolo Spurio +Cc: Fernando Pacheco +Cc: Chris Wilson +Cc: Jani Nikula +Cc: Joonas Lahtinen +Cc: Rodrigo Vivi +Cc: Tvrtko Ursulin +Cc: intel-gfx@lists.freedesktop.org +Cc: stable@vger.kernel.org # v5.3+ +Signed-off-by: John Harrison +Link: https://patchwork.freedesktop.org/patch/msgid/20230902171039.2229126186d697dbcf62d6d8@otheo.eu +(cherry picked from commit 0f3fa942d91165c2702577e9274d2ee1c7212afc) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + 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"); diff --git a/queue-6.1/drm-meson-fix-memory-leak-on-hpd_notify-callback.patch b/queue-6.1/drm-meson-fix-memory-leak-on-hpd_notify-callback.patch new file mode 100644 index 00000000000..49d1d31cd06 --- /dev/null +++ b/queue-6.1/drm-meson-fix-memory-leak-on-hpd_notify-callback.patch @@ -0,0 +1,42 @@ +From 099f0af9d98231bb74956ce92508e87cbcb896be Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 14 Sep 2023 16:10:15 +0300 +Subject: drm/meson: fix memory leak on ->hpd_notify callback + +From: Jani Nikula + +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 +Cc: Sam Ravnborg +Cc: Martin Blumenstingl +Cc: Neil Armstrong +Cc: Kevin Hilman +Cc: Jerome Brunet +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 +Reviewed-by: Neil Armstrong +Signed-off-by: Neil Armstrong +Link: https://patchwork.freedesktop.org/patch/msgid/20230914131015.2472029-1-jani.nikula@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-6.1/drm-tests-fix-incorrect-argument-in-drm_test_mm_insert_range.patch b/queue-6.1/drm-tests-fix-incorrect-argument-in-drm_test_mm_insert_range.patch new file mode 100644 index 00000000000..96aaa220295 --- /dev/null +++ b/queue-6.1/drm-tests-fix-incorrect-argument-in-drm_test_mm_insert_range.patch @@ -0,0 +1,49 @@ +From 2ba157983974ae1b6aaef7d4953812020d6f1eb5 Mon Sep 17 00:00:00 2001 +From: Janusz Krzysztofik +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 + +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 +Cc: "Maíra Canal" +Cc: Arthur Grillo +Cc: Javier Martinez Canillas +Cc: Daniel Latypov +Cc: stable@vger.kernel.org # v6.1+ +Reviewed-by: Maíra Canal +Signed-off-by: Maíra Canal +Link: https://patchwork.freedesktop.org/patch/msgid/20230911130323.7037-2-janusz.krzysztofik@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.1/fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch b/queue-6.1/fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch new file mode 100644 index 00000000000..fae951a4dbc --- /dev/null +++ b/queue-6.1/fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch @@ -0,0 +1,63 @@ +From 7c3151585730b7095287be8162b846d31e6eee61 Mon Sep 17 00:00:00 2001 +From: Greg Ungerer +Date: Thu, 7 Sep 2023 11:18:08 +1000 +Subject: fs: binfmt_elf_efpic: fix personality for ELF-FDPIC + +From: Greg Ungerer + +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 +Cc: Al Viro +Cc: Christian Brauner +Cc: Eric W. Biederman +Cc: Greg Ungerer +Cc: Kees Cook +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.1/fs-smb-client-reset-password-pointer-to-null.patch b/queue-6.1/fs-smb-client-reset-password-pointer-to-null.patch new file mode 100644 index 00000000000..52bfe29e3a7 --- /dev/null +++ b/queue-6.1/fs-smb-client-reset-password-pointer-to-null.patch @@ -0,0 +1,31 @@ +From e6e43b8aa7cd3c3af686caf0c2e11819a886d705 Mon Sep 17 00:00:00 2001 +From: Quang Le +Date: Fri, 29 Sep 2023 00:44:13 +0700 +Subject: fs/smb/client: Reset password pointer to NULL + +From: Quang Le + +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 +Reviewed-by: Namjae Jeon +Signed-off-by: Quang Le +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-6.1/media-uvcvideo-fix-oob-read.patch b/queue-6.1/media-uvcvideo-fix-oob-read.patch new file mode 100644 index 00000000000..6531c34a9a8 --- /dev/null +++ b/queue-6.1/media-uvcvideo-fix-oob-read.patch @@ -0,0 +1,37 @@ +From 41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Thu, 20 Jul 2023 17:46:54 +0000 +Subject: media: uvcvideo: Fix OOB read + +From: Ricardo Ribalda + +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 +Signed-off-by: Ricardo Ribalda +Reviewed-by: Sergey Senozhatsky +Reviewed-by: Laurent Pinchart +Signed-off-by: Laurent Pinchart +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/mm-damon-vaddr-test-fix-memory-leak-in-damon_do_test_apply_three_regions.patch b/queue-6.1/mm-damon-vaddr-test-fix-memory-leak-in-damon_do_test_apply_three_regions.patch new file mode 100644 index 00000000000..fe9fb3657b1 --- /dev/null +++ b/queue-6.1/mm-damon-vaddr-test-fix-memory-leak-in-damon_do_test_apply_three_regions.patch @@ -0,0 +1,168 @@ +From 45120b15743fa7c0aa53d5db6dfb4c8f87be4abd Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +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 + +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: + [] kmalloc_trace+0x27/0xa0 + [] damon_new_target+0x3f/0x1b0 + [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 + [] damon_test_apply_three_regions1+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] damon_new_region+0x22/0x1c0 + [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 + [] damon_test_apply_three_regions1+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] kmalloc_trace+0x27/0xa0 + [] damon_new_target+0x3f/0x1b0 + [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 + [] damon_test_apply_three_regions2+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] damon_new_region+0x22/0x1c0 + [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 + [] damon_test_apply_three_regions2+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] kmalloc_trace+0x27/0xa0 + [] damon_new_target+0x3f/0x1b0 + [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 + [] damon_test_apply_three_regions3+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] damon_new_region+0x22/0x1c0 + [] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 + [] damon_test_apply_three_regions3+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] damon_new_region+0x22/0x1c0 + [] damon_set_regions+0x4c2/0x8e0 + [] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0 + [] damon_test_apply_three_regions3+0x21e/0x260 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] kmalloc_trace+0x27/0xa0 + [] damon_new_target+0x3f/0x1b0 + [] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 + [] damon_test_apply_three_regions4+0x1cd/0x210 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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: + [] damon_new_region+0x22/0x1c0 + [] damon_set_regions+0x4c2/0x8e0 + [] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0 + [] damon_test_apply_three_regions4+0x1cd/0x210 + [] kunit_generic_run_threadfn_adapter+0x4a/0x90 + [] kthread+0x2b6/0x380 + [] ret_from_fork+0x2d/0x70 + [] 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 +Reviewed-by: SeongJae Park +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + + /* diff --git a/queue-6.1/mm-memcontrol-fix-gfp_nofs-recursion-in-memory.high-enforcement.patch b/queue-6.1/mm-memcontrol-fix-gfp_nofs-recursion-in-memory.high-enforcement.patch new file mode 100644 index 00000000000..2d040c48f91 --- /dev/null +++ b/queue-6.1/mm-memcontrol-fix-gfp_nofs-recursion-in-memory.high-enforcement.patch @@ -0,0 +1,134 @@ +From 9ea9cb00a82b53ec39630eac718776d37e41b35a Mon Sep 17 00:00:00 2001 +From: Johannes Weiner +Date: Thu, 14 Sep 2023 11:21:39 -0400 +Subject: mm: memcontrol: fix GFP_NOFS recursion in memory.high enforcement + +From: Johannes Weiner + +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 +Reported-by: Breno Leitao +Reported-by: Josef Bacik +Acked-by: Shakeel Butt +Acked-by: Michal Hocko +Cc: Roman Gushchin +Cc: Muchun Song +Cc: [5.17+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.1/mm-slab_common-fix-slab_caches-list-corruption-after-kmem_cache_destroy.patch b/queue-6.1/mm-slab_common-fix-slab_caches-list-corruption-after-kmem_cache_destroy.patch new file mode 100644 index 00000000000..d78da2f69f8 --- /dev/null +++ b/queue-6.1/mm-slab_common-fix-slab_caches-list-corruption-after-kmem_cache_destroy.patch @@ -0,0 +1,87 @@ +From 46a9ea6681907a3be6b6b0d43776dccc62cad6cf Mon Sep 17 00:00:00 2001 +From: Rafael Aquini +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 + +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 +Cc: stable@vger.kernel.org +Reviewed-by: Waiman Long +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch b/queue-6.1/net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch new file mode 100644 index 00000000000..f4c7339eeb3 --- /dev/null +++ b/queue-6.1/net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch @@ -0,0 +1,44 @@ +From e0b65f9b81fef180cf5f103adecbe5505c961153 Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +Date: Wed, 13 Sep 2023 08:26:47 +0300 +Subject: net: thunderbolt: Fix TCPv6 GSO checksum calculation + +From: Mika Westerberg + +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 +Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") +Cc: stable@vger.kernel.org +Signed-off-by: Mika Westerberg +Reviewed-by: Eric Dumazet +Reviewed-by: Jiri Pirko +Reviewed-by: Jiri Pirko +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.1/power-supply-ab8500-set-typing-and-props.patch b/queue-6.1/power-supply-ab8500-set-typing-and-props.patch new file mode 100644 index 00000000000..bb689d04cca --- /dev/null +++ b/queue-6.1/power-supply-ab8500-set-typing-and-props.patch @@ -0,0 +1,85 @@ +From dc77721ea4aa1e8937e2436f230b5a69065cc508 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 13 Jun 2023 23:31:50 +0200 +Subject: power: supply: ab8500: Set typing and props + +From: Linus Walleij + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Linus Walleij +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.1/power-supply-rk817-add-missing-module-alias.patch b/queue-6.1/power-supply-rk817-add-missing-module-alias.patch new file mode 100644 index 00000000000..437c6da617a --- /dev/null +++ b/queue-6.1/power-supply-rk817-add-missing-module-alias.patch @@ -0,0 +1,33 @@ +From cbcdfbf5a6cd66e47e5ee5d49c4c5a27a07ba082 Mon Sep 17 00:00:00 2001 +From: Nicolas Frattaroli +Date: Mon, 12 Jun 2023 16:36:52 +0200 +Subject: power: supply: rk817: Add missing module alias + +From: Nicolas Frattaroli + +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 +Reviewed-by: Chris Morgan +Link: https://lore.kernel.org/r/20230612143651.959646-2-frattaroli.nicolas@gmail.com +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + 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 "); + MODULE_AUTHOR("Chris Morgan "); + MODULE_LICENSE("GPL"); ++MODULE_ALIAS("platform:rk817-charger"); diff --git a/queue-6.1/revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch b/queue-6.1/revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch new file mode 100644 index 00000000000..c21f534dda3 --- /dev/null +++ b/queue-6.1/revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch @@ -0,0 +1,39 @@ +From a275ab62606bcd894ddff09460f7d253828313dc Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Sun, 17 Sep 2023 19:26:46 -0400 +Subject: Revert "SUNRPC dont update timeout value on connection reset" + +From: Trond Myklebust + +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 +Signed-off-by: Anna Schumaker +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/ring-buffer-update-shortest_full-in-polling.patch b/queue-6.1/ring-buffer-update-shortest_full-in-polling.patch new file mode 100644 index 00000000000..032e65869f2 --- /dev/null +++ b/queue-6.1/ring-buffer-update-shortest_full-in-polling.patch @@ -0,0 +1,66 @@ +From 1e0cb399c7653462d9dadf8ab9425337c355d358 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Fri, 29 Sep 2023 18:01:13 -0400 +Subject: ring-buffer: Update "shortest_full" in polling + +From: Steven Rostedt (Google) + +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 +Cc: Mark Rutland +Fixes: 42fb0a1e84ff ("tracing/ring-buffer: Have polling block on watermark") +Reported-by: Julia Lawall +Tested-by: Julia Lawall +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/series b/queue-6.1/series index f20be435980..27360671f74 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -229,3 +229,28 @@ asoc-amd-yc-fix-non-functional-mic-on-lenovo-82qf-and-82ug.patch 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 diff --git a/queue-6.1/timers-tag-hr-timer-softirq-as-hotplug-safe.patch b/queue-6.1/timers-tag-hr-timer-softirq-as-hotplug-safe.patch new file mode 100644 index 00000000000..7ad9ca1019c --- /dev/null +++ b/queue-6.1/timers-tag-hr-timer-softirq-as-hotplug-safe.patch @@ -0,0 +1,60 @@ +From 1a6a464774947920dcedcf7409be62495c7cedd0 Mon Sep 17 00:00:00 2001 +From: Frederic Weisbecker +Date: Tue, 12 Sep 2023 12:44:06 +0200 +Subject: timers: Tag (hr)timer softirq as hotplug safe + +From: Frederic Weisbecker + +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 +Signed-off-by: Thomas Gleixner +Reviewed-by: Joel Fernandes (Google) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230912104406.312185-6-frederic@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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.