--- /dev/null
+From 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Fri, 8 Sep 2023 20:04:52 +0900
+Subject: ata: libata-core: Do not register PM operations for SAS ports
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 upstream.
+
+libsas does its own domain based power management of ports. For such
+ports, libata should not use a device type defining power management
+operations as executing these operations for suspend/resume in addition
+to libsas calls to ata_sas_port_suspend() and ata_sas_port_resume() is
+not necessary (and likely dangerous to do, even though problems are not
+seen currently).
+
+Introduce the new ata_port_sas_type device_type for ports managed by
+libsas. This new device type is used in ata_tport_add() and is defined
+without power management operations.
+
+Fixes: 2fcbdcb4c802 ("[SCSI] libata: export ata_port suspend/resume infrastructure for sas")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: John Garry <john.g.garry@oracle.com>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 2 +-
+ drivers/ata/libata-transport.c | 9 ++++++++-
+ drivers/ata/libata.h | 2 ++
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -5192,7 +5192,7 @@ EXPORT_SYMBOL_GPL(ata_host_resume);
+ #endif
+
+ const struct device_type ata_port_type = {
+- .name = "ata_port",
++ .name = ATA_PORT_TYPE_NAME,
+ #ifdef CONFIG_PM
+ .pm = &ata_port_pm_ops,
+ #endif
+--- a/drivers/ata/libata-transport.c
++++ b/drivers/ata/libata-transport.c
+@@ -266,6 +266,10 @@ void ata_tport_delete(struct ata_port *a
+ put_device(dev);
+ }
+
++static const struct device_type ata_port_sas_type = {
++ .name = ATA_PORT_TYPE_NAME,
++};
++
+ /** ata_tport_add - initialize a transport ATA port structure
+ *
+ * @parent: parent device
+@@ -283,7 +287,10 @@ int ata_tport_add(struct device *parent,
+ struct device *dev = &ap->tdev;
+
+ device_initialize(dev);
+- dev->type = &ata_port_type;
++ if (ap->flags & ATA_FLAG_SAS_HOST)
++ dev->type = &ata_port_sas_type;
++ else
++ dev->type = &ata_port_type;
+
+ dev->parent = parent;
+ ata_host_get(ap->host);
+--- a/drivers/ata/libata.h
++++ b/drivers/ata/libata.h
+@@ -30,6 +30,8 @@ enum {
+ ATA_DNXFER_QUIET = (1 << 31),
+ };
+
++#define ATA_PORT_TYPE_NAME "ata_port"
++
+ extern atomic_t ata_print_id;
+ extern int atapi_passthru16;
+ extern int libata_fua;
--- /dev/null
+From 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Mon, 4 Sep 2023 20:38:13 +0900
+Subject: ata: libata-core: Fix ata_port_request_pm() locking
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 upstream.
+
+The function ata_port_request_pm() checks the port flag
+ATA_PFLAG_PM_PENDING and calls ata_port_wait_eh() if this flag is set to
+ensure that power management operations for a port are not scheduled
+simultaneously. However, this flag check is done without holding the
+port lock.
+
+Fix this by taking the port lock on entry to the function and checking
+the flag under this lock. The lock is released and re-taken if
+ata_port_wait_eh() needs to be called. The two WARN_ON() macros checking
+that the ATA_PFLAG_PM_PENDING flag was cleared are removed as the first
+call is racy and the second one done without holding the port lock.
+
+Fixes: 5ef41082912b ("ata: add ata port system PM callbacks")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4999,17 +4999,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) {
+@@ -5021,10 +5023,8 @@ static void ata_port_request_pm(struct a
+
+ spin_unlock_irqrestore(ap->lock, flags);
+
+- if (!async) {
++ if (!async)
+ ata_port_wait_eh(ap);
+- WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
+- }
+ }
+
+ /*
--- /dev/null
+From 84d76529c650f887f1e18caee72d6f0589e1baf9 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Sat, 26 Aug 2023 13:07:36 +0900
+Subject: ata: libata-core: Fix port and device removal
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 84d76529c650f887f1e18caee72d6f0589e1baf9 upstream.
+
+Whenever an ATA adapter driver is removed (e.g. rmmod),
+ata_port_detach() is called repeatedly for all the adapter ports to
+remove (unload) the devices attached to the port and delete the port
+device itself. Removing of devices is done using libata EH with the
+ATA_PFLAG_UNLOADING port flag set. This causes libata EH to execute
+ata_eh_unload() which disables all devices attached to the port.
+
+ata_port_detach() finishes by calling scsi_remove_host() to remove the
+scsi host associated with the port. This function will trigger the
+removal of all scsi devices attached to the host and in the case of
+disks, calls to sd_shutdown() which will flush the device write cache
+and stop the device. However, given that the devices were already
+disabled by ata_eh_unload(), the synchronize write cache command and
+start stop unit commands fail. E.g. running "rmmod ahci" with first
+removing sd_mod results in error messages like:
+
+ata13.00: disable device
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+sd 0:0:0:0: [sda] Stopping disk
+sd 0:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+
+Fix this by removing all scsi devices of the ata devices connected to
+the port before scheduling libata EH to disable the ATA devices.
+
+Fixes: 720ba12620ee ("[PATCH] libata-hp: update unload-unplug")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
+Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -5940,11 +5940,30 @@ static void ata_port_detach(struct ata_p
+ if (!ap->ops->error_handler)
+ goto skip_eh;
+
+- /* tell EH we're leaving & flush EH */
++ /* Wait for any ongoing EH */
++ ata_port_wait_eh(ap);
++
++ mutex_lock(&ap->scsi_scan_mutex);
+ spin_lock_irqsave(ap->lock, flags);
++
++ /* Remove scsi devices */
++ ata_for_each_link(link, ap, HOST_FIRST) {
++ ata_for_each_dev(dev, link, ALL) {
++ if (dev->sdev) {
++ spin_unlock_irqrestore(ap->lock, flags);
++ scsi_remove_device(dev->sdev);
++ spin_lock_irqsave(ap->lock, flags);
++ dev->sdev = NULL;
++ }
++ }
++ }
++
++ /* Tell EH to disable all devices */
+ ap->pflags |= ATA_PFLAG_UNLOADING;
+ ata_port_schedule_eh(ap);
++
+ spin_unlock_irqrestore(ap->lock, flags);
++ mutex_unlock(&ap->scsi_scan_mutex);
+
+ /* wait till EH commits suicide */
+ ata_port_wait_eh(ap);
--- /dev/null
+From 753a4d531bc518633ea88ac0ed02b25a16823d51 Mon Sep 17 00:00:00 2001
+From: Matthias Schiffer <mschiffer@universe-factory.net>
+Date: Fri, 22 Sep 2023 22:55:16 +0200
+Subject: ata: libata-sata: increase PMP SRST timeout to 10s
+
+From: Matthias Schiffer <mschiffer@universe-factory.net>
+
+commit 753a4d531bc518633ea88ac0ed02b25a16823d51 upstream.
+
+On certain SATA controllers, softreset fails after wakeup from S2RAM with
+the message "softreset failed (1st FIS failed)", sometimes resulting in
+drives not being detected again. With the increased timeout, this issue
+is avoided. Instead, "softreset failed (device not ready)" is now
+logged 1-2 times; this later failure seems to cause fewer problems
+however, and the drives are detected reliably once they've spun up and
+the probe is retried.
+
+The issue was observed with the primary SATA controller of the QNAP
+TS-453B, which is an "Intel Corporation Celeron/Pentium Silver Processor
+SATA Controller [8086:31e3] (rev 06)" integrated in the Celeron J4125 CPU,
+and the following drives:
+
+- Seagate IronWolf ST12000VN0008
+- Seagate IronWolf ST8000NE0004
+
+The SATA controller seems to be more relevant to this issue than the
+drives, as the same drives are always detected reliably on the secondary
+SATA controller on the same board (an ASMedia 106x) without any "softreset
+failed" errors even without the increased timeout.
+
+Fixes: e7d3ef13d52a ("libata: change drive ready wait after hard reset to 5s")
+Cc: stable@vger.kernel.org
+Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/libata.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/libata.h
++++ b/include/linux/libata.h
+@@ -301,7 +301,7 @@ enum {
+ * advised to wait only for the following duration before
+ * doing SRST.
+ */
+- ATA_TMOUT_PMP_SRST_WAIT = 5000,
++ ATA_TMOUT_PMP_SRST_WAIT = 10000,
+
+ /* When the LPM policy is set to ATA_LPM_MAX_POWER, there might
+ * be a spurious PHY event, so ignore the first PHY event that
--- /dev/null
+From c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Fri, 15 Sep 2023 10:34:28 -0700
+Subject: bpf: Fix BTF_ID symbol generation collision in tools/
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 upstream.
+
+Marcus and Satya reported an issue where BTF_ID macro generates same
+symbol in separate objects and that breaks final vmlinux link.
+
+ ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
+ '__BTF_ID__struct__cgroup__624' is already defined
+
+This can be triggered under specific configs when __COUNTER__ happens to
+be the same for the same symbol in two different translation units,
+which is already quite unlikely to happen.
+
+Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
+not a complete fix, but it would help for now and meanwhile we can work
+on better solution as suggested by Andrii.
+
+Cc: stable@vger.kernel.org
+Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
+Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
+Debugged-by: Nathan Chancellor <nathan@kernel.org>
+Co-developed-by: Jiri Olsa <jolsa@kernel.org>
+Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-2-263fc519c21f@google.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/include/linux/btf_ids.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/include/linux/btf_ids.h
++++ b/tools/include/linux/btf_ids.h
+@@ -38,7 +38,7 @@ asm( \
+ ____BTF_ID(symbol)
+
+ #define __ID(prefix) \
+- __PASTE(prefix, __COUNTER__)
++ __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
+
+ /*
+ * The BTF_ID defines unique symbol for each ID pointing
--- /dev/null
+From 8f908db77782630c45ba29dac35c434b5ce0b730 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+Date: Fri, 15 Sep 2023 10:34:27 -0700
+Subject: bpf: Fix BTF_ID symbol generation collision
+
+From: Jiri Olsa <jolsa@kernel.org>
+
+commit 8f908db77782630c45ba29dac35c434b5ce0b730 upstream.
+
+Marcus and Satya reported an issue where BTF_ID macro generates same
+symbol in separate objects and that breaks final vmlinux link.
+
+ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
+'__BTF_ID__struct__cgroup__624' is already defined
+
+This can be triggered under specific configs when __COUNTER__ happens to
+be the same for the same symbol in two different translation units,
+which is already quite unlikely to happen.
+
+Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
+not a complete fix, but it would help for now and meanwhile we can work
+on better solution as suggested by Andrii.
+
+Cc: stable@vger.kernel.org
+Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
+Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
+Debugged-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20230915-bpf_collision-v3-1-263fc519c21f@google.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/btf_ids.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/btf_ids.h
++++ b/include/linux/btf_ids.h
+@@ -38,7 +38,7 @@ asm( \
+ ____BTF_ID(symbol)
+
+ #define __ID(prefix) \
+- __PASTE(prefix, __COUNTER__)
++ __PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
+
+ /*
+ * The BTF_ID defines unique symbol for each ID pointing
--- /dev/null
+From 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Mon, 18 Sep 2023 10:34:51 -0400
+Subject: btrfs: properly report 0 avail for very full file systems
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c upstream.
+
+A user reported some issues with smaller file systems that get very
+full. While investigating this issue I noticed that df wasn't showing
+100% full, despite having 0 chunk space and having < 1MiB of available
+metadata space.
+
+This turns out to be an overflow issue, we're doing:
+
+ total_available_metadata_space - SZ_4M < global_block_rsv_size
+
+to determine if there's not enough space to make metadata allocations,
+which overflows if total_available_metadata_space is < 4M. Fix this by
+checking to see if our available space is greater than the 4M threshold.
+This makes df properly report 100% usage on the file system.
+
+CC: stable@vger.kernel.org # 4.14+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/super.c
++++ b/fs/btrfs/super.c
+@@ -2364,7 +2364,7 @@ static int btrfs_statfs(struct dentry *d
+ * calculated f_bavail.
+ */
+ if (!mixed && block_rsv->space_info->full &&
+- total_free_meta - thresh < block_rsv->size)
++ (total_free_meta < thresh || total_free_meta - thresh < block_rsv->size))
+ buf->f_bavail = 0;
+
+ buf->f_type = BTRFS_SUPER_MAGIC;
--- /dev/null
+From 099f0af9d98231bb74956ce92508e87cbcb896be Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Thu, 14 Sep 2023 16:10:15 +0300
+Subject: drm/meson: fix memory leak on ->hpd_notify callback
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
+
+The EDID returned by drm_bridge_get_edid() needs to be freed.
+
+Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR")
+Cc: Neil Armstrong <narmstrong@baylibre.com>
+Cc: Sam Ravnborg <sam@ravnborg.org>
+Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: Neil Armstrong <neil.armstrong@linaro.org>
+Cc: Kevin Hilman <khilman@baylibre.com>
+Cc: Jerome Brunet <jbrunet@baylibre.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: linux-amlogic@lists.infradead.org
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: stable@vger.kernel.org # v5.17+
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230914131015.2472029-1-jani.nikula@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/meson/meson_encoder_hdmi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
++++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+@@ -326,6 +326,8 @@ static void meson_encoder_hdmi_hpd_notif
+ return;
+
+ cec_notifier_set_phys_addr_from_edid(encoder_hdmi->cec_notifier, edid);
++
++ kfree(edid);
+ } else
+ cec_notifier_phys_addr_invalidate(encoder_hdmi->cec_notifier);
+ }
--- /dev/null
+From 7c3151585730b7095287be8162b846d31e6eee61 Mon Sep 17 00:00:00 2001
+From: Greg Ungerer <gerg@kernel.org>
+Date: Thu, 7 Sep 2023 11:18:08 +1000
+Subject: fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
+
+From: Greg Ungerer <gerg@kernel.org>
+
+commit 7c3151585730b7095287be8162b846d31e6eee61 upstream.
+
+The elf-fdpic loader hard sets the process personality to either
+PER_LINUX_FDPIC for true elf-fdpic binaries or to PER_LINUX for normal ELF
+binaries (in this case they would be constant displacement compiled with
+-pie for example). The problem with that is that it will lose any other
+bits that may be in the ELF header personality (such as the "bug
+emulation" bits).
+
+On the ARM architecture the ADDR_LIMIT_32BIT flag is used to signify a
+normal 32bit binary - as opposed to a legacy 26bit address binary. This
+matters since start_thread() will set the ARM CPSR register as required
+based on this flag. If the elf-fdpic loader loses this bit the process
+will be mis-configured and crash out pretty quickly.
+
+Modify elf-fdpic loader personality setting so that it preserves the upper
+three bytes by using the SET_PERSONALITY macro to set it. This macro in
+the generic case sets PER_LINUX and preserves the upper bytes.
+Architectures can override this for their specific use case, and ARM does
+exactly this.
+
+The problem shows up quite easily running under qemu using the ARM
+architecture, but not necessarily on all types of real ARM hardware. If
+the underlying ARM processor does not support the legacy 26-bit addressing
+mode then everything will work as expected.
+
+Link: https://lkml.kernel.org/r/20230907011808.2985083-1-gerg@kernel.org
+Fixes: 1bde925d23547 ("fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries")
+Signed-off-by: Greg Ungerer <gerg@kernel.org>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Greg Ungerer <gerg@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_elf_fdpic.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/binfmt_elf_fdpic.c
++++ b/fs/binfmt_elf_fdpic.c
+@@ -345,10 +345,9 @@ static int load_elf_fdpic_binary(struct
+ /* there's now no turning back... the old userspace image is dead,
+ * defunct, deceased, etc.
+ */
++ SET_PERSONALITY(exec_params.hdr);
+ if (elf_check_fdpic(&exec_params.hdr))
+- set_personality(PER_LINUX_FDPIC);
+- else
+- set_personality(PER_LINUX);
++ current->personality |= PER_LINUX_FDPIC;
+ if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
+ current->personality |= READ_IMPLIES_EXEC;
+
--- /dev/null
+From e0b65f9b81fef180cf5f103adecbe5505c961153 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Wed, 13 Sep 2023 08:26:47 +0300
+Subject: net: thunderbolt: Fix TCPv6 GSO checksum calculation
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit e0b65f9b81fef180cf5f103adecbe5505c961153 upstream.
+
+Alex reported that running ssh over IPv6 does not work with
+Thunderbolt/USB4 networking driver. The reason for that is that driver
+should call skb_is_gso() before calling skb_is_gso_v6(), and it should
+not return false after calculates the checksum successfully. This probably
+was a copy paste error from the original driver where it was done properly.
+
+Reported-by: Alex Balcanquall <alex@alexbal.com>
+Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Jiri Pirko <jiri@nvidia.com>
+Reviewed-by: Jiri Pirko <jiri@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/thunderbolt.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/thunderbolt.c
++++ b/drivers/net/thunderbolt.c
+@@ -993,12 +993,11 @@ static bool tbnet_xmit_csum_and_map(stru
+ *tucso = ~csum_tcpudp_magic(ip_hdr(skb)->saddr,
+ ip_hdr(skb)->daddr, 0,
+ ip_hdr(skb)->protocol, 0);
+- } else if (skb_is_gso_v6(skb)) {
++ } else if (skb_is_gso(skb) && skb_is_gso_v6(skb)) {
+ tucso = dest + ((void *)&(tcp_hdr(skb)->check) - data);
+ *tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr, 0,
+ IPPROTO_TCP, 0);
+- return false;
+ } else if (protocol == htons(ETH_P_IPV6)) {
+ tucso = dest + skb_checksum_start_offset(skb) + skb->csum_offset;
+ *tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
--- /dev/null
+From 578d7699e5c2add8c2e9549d9d75dfb56c460cb3 Mon Sep 17 00:00:00 2001
+From: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
+Date: Thu, 14 Sep 2023 12:30:20 -0400
+Subject: proc: nommu: /proc/<pid>/maps: release mmap read lock
+
+From: Ben Wolsieffer <Ben.Wolsieffer@hefring.com>
+
+commit 578d7699e5c2add8c2e9549d9d75dfb56c460cb3 upstream.
+
+The no-MMU implementation of /proc/<pid>/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/<pid>/maps. To actually reproduce the bug, compile the
+following code as 'proc_maps_bug':
+
+#include <stdio.h>
+#include <unistd.h>
+#include <sys/mman.h>
+
+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 <ben.wolsieffer@hefring.com>
+Acked-by: Oleg Nesterov <oleg@redhat.com>
+Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
+Cc: Greg Ungerer <gerg@uclinux.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/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)
--- /dev/null
+From a275ab62606bcd894ddff09460f7d253828313dc Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Sun, 17 Sep 2023 19:26:46 -0400
+Subject: Revert "SUNRPC dont update timeout value on connection reset"
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+commit a275ab62606bcd894ddff09460f7d253828313dc upstream.
+
+This reverts commit 88428cc4ae7abcc879295fbb19373dd76aad2bdd.
+
+The problem this commit is intended to fix was comprehensively fixed
+in commit 7de62bc09fe6 ("SUNRPC dont update timeout value on connection
+reset").
+Since then, this commit has been preventing the correct timeout of soft
+mounted requests.
+
+Cc: stable@vger.kernel.org # 5.9.x: 09252177d5f9: SUNRPC: Handle major timeout in xprt_adjust_timeout()
+Cc: stable@vger.kernel.org # 5.9.x: 7de62bc09fe6: SUNRPC dont update timeout value on connection reset
+Cc: stable@vger.kernel.org # 5.9.x
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sunrpc/clnt.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/sunrpc/clnt.c
++++ b/net/sunrpc/clnt.c
+@@ -2392,8 +2392,7 @@ call_status(struct rpc_task *task)
+ goto out_exit;
+ }
+ task->tk_action = call_encode;
+- if (status != -ECONNRESET && status != -ECONNABORTED)
+- rpc_check_timeout(task);
++ rpc_check_timeout(task);
+ return;
+ out_exit:
+ rpc_call_rpcerror(task, status);
--- /dev/null
+From 1e0cb399c7653462d9dadf8ab9425337c355d358 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Fri, 29 Sep 2023 18:01:13 -0400
+Subject: ring-buffer: Update "shortest_full" in polling
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 1e0cb399c7653462d9dadf8ab9425337c355d358 upstream.
+
+It was discovered that the ring buffer polling was incorrectly stating
+that read would not block, but that's because polling did not take into
+account that reads will block if the "buffer-percent" was set. Instead,
+the ring buffer polling would say reads would not block if there was any
+data in the ring buffer. This was incorrect behavior from a user space
+point of view. This was fixed by commit 42fb0a1e84ff by having the polling
+code check if the ring buffer had more data than what the user specified
+"buffer percent" had.
+
+The problem now is that the polling code did not register itself to the
+writer that it wanted to wait for a specific "full" value of the ring
+buffer. The result was that the writer would wake the polling waiter
+whenever there was a new event. The polling waiter would then wake up, see
+that there's not enough data in the ring buffer to notify user space and
+then go back to sleep. The next event would wake it up again.
+
+Before the polling fix was added, the code would wake up around 100 times
+for a hackbench 30 benchmark. After the "fix", due to the constant waking
+of the writer, it would wake up over 11,0000 times! It would never leave
+the kernel, so the user space behavior was still "correct", but this
+definitely is not the desired effect.
+
+To fix this, have the polling code add what it's waiting for to the
+"shortest_full" variable, to tell the writer not to wake it up if the
+buffer is not as full as it expects to be.
+
+Note, after this fix, it appears that the waiter is now woken up around 2x
+the times it was before (~200). This is a tremendous improvement from the
+11,000 times, but I will need to spend some time to see why polling is
+more aggressive in its wakeups than the read blocking code.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230929180113.01c2cae3@rorschach.local.home
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Fixes: 42fb0a1e84ff ("tracing/ring-buffer: Have polling block on watermark")
+Reported-by: Julia Lawall <julia.lawall@inria.fr>
+Tested-by: Julia Lawall <julia.lawall@inria.fr>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1106,6 +1106,9 @@ __poll_t ring_buffer_poll_wait(struct tr
+ if (full) {
+ poll_wait(filp, &work->full_waiters, poll_table);
+ work->full_waiters_pending = true;
++ if (!cpu_buffer->shortest_full ||
++ cpu_buffer->shortest_full > full)
++ cpu_buffer->shortest_full = full;
+ } else {
+ poll_wait(filp, &work->waiters, poll_table);
+ work->waiters_pending = true;
kernel-sched-modify-initial-boot-task-idle-setup.patch
sched-rt-fix-live-lock-between-select_fallback_rq-and-rt-push.patch
io_uring-fs-remove-sqe-rw_flags-checking-from-linkat.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
+drm-meson-fix-memory-leak-on-hpd_notify-callback.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
