From: Greg Kroah-Hartman Date: Wed, 4 Oct 2023 16:05:02 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v6.5.6~10 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5725ee792c2645ea4a00381a37c898a7477cf0ae;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: 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-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 fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch proc-nommu-proc-pid-maps-release-mmap-read-lock.patch revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch ring-buffer-update-shortest_full-in-polling.patch --- diff --git a/queue-5.10/ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch b/queue-5.10/ata-libata-core-do-not-register-pm-operations-for-sas-ports.patch new file mode 100644 index 00000000000..99781396f03 --- /dev/null +++ b/queue-5.10/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 +@@ -5167,7 +5167,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-5.10/ata-libata-core-fix-ata_port_request_pm-locking.patch b/queue-5.10/ata-libata-core-fix-ata_port_request_pm-locking.patch new file mode 100644 index 00000000000..c9f69bd4264 --- /dev/null +++ b/queue-5.10/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 +@@ -4974,17 +4974,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) { +@@ -4996,10 +4998,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-5.10/ata-libata-core-fix-port-and-device-removal.patch b/queue-5.10/ata-libata-core-fix-port-and-device-removal.patch new file mode 100644 index 00000000000..24e236fa042 --- /dev/null +++ b/queue-5.10/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 +@@ -5915,11 +5915,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-5.10/ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch b/queue-5.10/ata-libata-sata-increase-pmp-srst-timeout-to-10s.patch new file mode 100644 index 00000000000..5b21276b6df --- /dev/null +++ b/queue-5.10/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 +@@ -297,7 +297,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-5.10/bpf-fix-btf_id-symbol-generation-collision-in-tools.patch b/queue-5.10/bpf-fix-btf_id-symbol-generation-collision-in-tools.patch new file mode 100644 index 00000000000..3b967b0a10b --- /dev/null +++ b/queue-5.10/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-5.10/bpf-fix-btf_id-symbol-generation-collision.patch b/queue-5.10/bpf-fix-btf_id-symbol-generation-collision.patch new file mode 100644 index 00000000000..7cb90df2b0c --- /dev/null +++ b/queue-5.10/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 +@@ -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-5.10/btrfs-properly-report-0-avail-for-very-full-file-systems.patch b/queue-5.10/btrfs-properly-report-0-avail-for-very-full-file-systems.patch new file mode 100644 index 00000000000..100881463d2 --- /dev/null +++ b/queue-5.10/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 +@@ -2267,7 +2267,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-5.10/fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch b/queue-5.10/fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch new file mode 100644 index 00000000000..fae951a4dbc --- /dev/null +++ b/queue-5.10/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-5.10/net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch b/queue-5.10/net-thunderbolt-fix-tcpv6-gso-checksum-calculation.patch new file mode 100644 index 00000000000..b26af3f0cd4 --- /dev/null +++ b/queue-5.10/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 +@@ -958,12 +958,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-5.10/proc-nommu-proc-pid-maps-release-mmap-read-lock.patch b/queue-5.10/proc-nommu-proc-pid-maps-release-mmap-read-lock.patch new file mode 100644 index 00000000000..08315199b3d --- /dev/null +++ b/queue-5.10/proc-nommu-proc-pid-maps-release-mmap-read-lock.patch @@ -0,0 +1,113 @@ +From 578d7699e5c2add8c2e9549d9d75dfb56c460cb3 Mon Sep 17 00:00:00 2001 +From: Ben Wolsieffer +Date: Thu, 14 Sep 2023 12:30:20 -0400 +Subject: proc: nommu: /proc//maps: release mmap read lock + +From: Ben Wolsieffer + +commit 578d7699e5c2add8c2e9549d9d75dfb56c460cb3 upstream. + +The no-MMU implementation of /proc//map doesn't normally release +the mmap read lock, because it uses !IS_ERR_OR_NULL(_vml) to determine +whether to release the lock. Since _vml is NULL when the end of the +mappings is reached, the lock is not released. + +Reading /proc/1/maps twice doesn't cause a hang because it only +takes the read lock, which can be taken multiple times and therefore +doesn't show any problem if the lock isn't released. Instead, you need +to perform some operation that attempts to take the write lock after +reading /proc//maps. To actually reproduce the bug, compile the +following code as 'proc_maps_bug': + +#include +#include +#include + +int main(int argc, char *argv[]) { + void *buf; + sleep(1); + buf = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + puts("mmap returned"); + return 0; +} + +Then, run: + + ./proc_maps_bug &; cat /proc/$!/maps; fg + +Without this patch, mmap() will hang and the command will never +complete. + +This code was incorrectly adapted from the MMU implementation, which at +the time released the lock in m_next() before returning the last entry. + +The MMU implementation has diverged further from the no-MMU version since +then, so this patch brings their locking and error handling into sync, +fixing the bug and hopefully avoiding similar issues in the future. + +Link: https://lkml.kernel.org/r/20230914163019.4050530-2-ben.wolsieffer@hefring.com +Fixes: 47fecca15c09 ("fs/proc/task_nommu.c: don't use priv->task->mm") +Signed-off-by: Ben Wolsieffer +Acked-by: Oleg Nesterov +Cc: Giulio Benetti +Cc: Greg Ungerer +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/task_nommu.c | 27 +++++++++++++++------------ + 1 file changed, 15 insertions(+), 12 deletions(-) + +--- a/fs/proc/task_nommu.c ++++ b/fs/proc/task_nommu.c +@@ -208,11 +208,16 @@ static void *m_start(struct seq_file *m, + return ERR_PTR(-ESRCH); + + mm = priv->mm; +- if (!mm || !mmget_not_zero(mm)) ++ if (!mm || !mmget_not_zero(mm)) { ++ put_task_struct(priv->task); ++ priv->task = NULL; + return NULL; ++ } + + if (mmap_read_lock_killable(mm)) { + mmput(mm); ++ put_task_struct(priv->task); ++ priv->task = NULL; + return ERR_PTR(-EINTR); + } + +@@ -221,23 +226,21 @@ static void *m_start(struct seq_file *m, + if (n-- == 0) + return p; + +- mmap_read_unlock(mm); +- mmput(mm); + return NULL; + } + +-static void m_stop(struct seq_file *m, void *_vml) ++static void m_stop(struct seq_file *m, void *v) + { + struct proc_maps_private *priv = m->private; ++ struct mm_struct *mm = priv->mm; + +- if (!IS_ERR_OR_NULL(_vml)) { +- mmap_read_unlock(priv->mm); +- mmput(priv->mm); +- } +- if (priv->task) { +- put_task_struct(priv->task); +- priv->task = NULL; +- } ++ if (!priv->task) ++ return; ++ ++ mmap_read_unlock(mm); ++ mmput(mm); ++ put_task_struct(priv->task); ++ priv->task = NULL; + } + + static void *m_next(struct seq_file *m, void *_p, loff_t *pos) diff --git a/queue-5.10/revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch b/queue-5.10/revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch new file mode 100644 index 00000000000..a2c44651e3d --- /dev/null +++ b/queue-5.10/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 +@@ -2354,8 +2354,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-5.10/ring-buffer-update-shortest_full-in-polling.patch b/queue-5.10/ring-buffer-update-shortest_full-in-polling.patch new file mode 100644 index 00000000000..feffd028431 --- /dev/null +++ b/queue-5.10/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 +@@ -1008,6 +1008,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-5.10/series b/queue-5.10/series index 7811b4ea111..ce04a693d38 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -153,3 +153,15 @@ netfilter-nf_tables-disallow-rule-removal-from-chain.patch alsa-hda-disable-power-save-for-solving-pop-issue-on-lenovo-thinkcentre-m70q.patch ata-libata-scsi-ignore-reserved-bits-for-report-supported-operation-codes.patch i2c-i801-unregister-tco_pdev-in-i801_probe-error-path.patch +revert-sunrpc-dont-update-timeout-value-on-connection-reset.patch +proc-nommu-proc-pid-maps-release-mmap-read-lock.patch +ring-buffer-update-shortest_full-in-polling.patch +btrfs-properly-report-0-avail-for-very-full-file-systems.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 +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 +fs-binfmt_elf_efpic-fix-personality-for-elf-fdpic.patch