--- /dev/null
+From 79336504781e7fee5ddaf046dcc186c8dfdf60b1 Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Fri, 12 Apr 2024 08:41:15 +0900
+Subject: ata: libata-scsi: Fix ata_scsi_dev_rescan() error path
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 79336504781e7fee5ddaf046dcc186c8dfdf60b1 upstream.
+
+Commit 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
+incorrectly handles failures of scsi_resume_device() in
+ata_scsi_dev_rescan(), leading to a double call to
+spin_unlock_irqrestore() to unlock a device port. Fix this by redefining
+the goto labels used in case of errors and only unlock the port
+scsi_scan_mutex when scsi_resume_device() fails.
+
+Bug found with the Smatch static checker warning:
+
+ drivers/ata/libata-scsi.c:4774 ata_scsi_dev_rescan()
+ error: double unlocked 'ap->lock' (orig line 4757)
+
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Fixes: 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-scsi.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -4667,7 +4667,7 @@ void ata_scsi_dev_rescan(struct work_str
+ * bail out.
+ */
+ if (ap->pflags & ATA_PFLAG_SUSPENDED)
+- goto unlock;
++ goto unlock_ap;
+
+ if (!sdev)
+ continue;
+@@ -4680,7 +4680,7 @@ void ata_scsi_dev_rescan(struct work_str
+ if (do_resume) {
+ ret = scsi_resume_device(sdev);
+ if (ret == -EWOULDBLOCK)
+- goto unlock;
++ goto unlock_scan;
+ dev->flags &= ~ATA_DFLAG_RESUMING;
+ }
+ ret = scsi_rescan_device(sdev);
+@@ -4688,12 +4688,13 @@ void ata_scsi_dev_rescan(struct work_str
+ spin_lock_irqsave(ap->lock, flags);
+
+ if (ret)
+- goto unlock;
++ goto unlock_ap;
+ }
+ }
+
+-unlock:
++unlock_ap:
+ spin_unlock_irqrestore(ap->lock, flags);
++unlock_scan:
+ mutex_unlock(&ap->scsi_scan_mutex);
+
+ /* Reschedule with a delay if scsi_rescan_device() returned an error */
--- /dev/null
+From b1f532a3b1e6d2e5559c7ace49322922637a28aa Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann <sven@narfation.org>
+Date: Mon, 12 Feb 2024 13:58:33 +0100
+Subject: batman-adv: Avoid infinite loop trying to resize local TT
+
+From: Sven Eckelmann <sven@narfation.org>
+
+commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream.
+
+If the MTU of one of an attached interface becomes too small to transmit
+the local translation table then it must be resized to fit inside all
+fragments (when enabled) or a single packet.
+
+But if the MTU becomes too low to transmit even the header + the VLAN
+specific part then the resizing of the local TT will never succeed. This
+can for example happen when the usable space is 110 bytes and 11 VLANs are
+on top of batman-adv. In this case, at least 116 byte would be needed.
+There will just be an endless spam of
+
+ batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
+
+in the log but the function will never finish. Problem here is that the
+timeout will be halved all the time and will then stagnate at 0 and
+therefore never be able to reduce the table even more.
+
+There are other scenarios possible with a similar result. The number of
+BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
+high to fit inside a packet. Such a scenario can therefore happen also with
+only a single VLAN + 7 non-purgable addresses - requiring at least 120
+bytes.
+
+While this should be handled proactively when:
+
+* interface with too low MTU is added
+* VLAN is added
+* non-purgeable local mac is added
+* MTU of an attached interface is reduced
+* fragmentation setting gets disabled (which most likely requires dropping
+ attached interfaces)
+
+not all of these scenarios can be prevented because batman-adv is only
+consuming events without the the possibility to prevent these actions
+(non-purgable MAC address added, MTU of an attached interface is reduced).
+It is therefore necessary to also make sure that the code is able to handle
+also the situations when there were already incompatible system
+configuration are present.
+
+Cc: stable@vger.kernel.org
+Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size")
+Reported-by: syzbot+a6a4b5bb3da165594cff@syzkaller.appspotmail.com
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/batman-adv/translation-table.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/batman-adv/translation-table.c
++++ b/net/batman-adv/translation-table.c
+@@ -3948,7 +3948,7 @@ void batadv_tt_local_resize_to_mtu(struc
+
+ spin_lock_bh(&bat_priv->tt.commit_lock);
+
+- while (true) {
++ while (timeout) {
+ table_size = batadv_tt_local_table_transmit_size(bat_priv);
+ if (packet_size_max >= table_size)
+ break;
--- /dev/null
+From 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 Mon Sep 17 00:00:00 2001
+From: Dmitry Antipov <dmantipov@yandex.ru>
+Date: Tue, 2 Apr 2024 14:32:05 +0300
+Subject: Bluetooth: Fix memory leak in hci_req_sync_complete()
+
+From: Dmitry Antipov <dmantipov@yandex.ru>
+
+commit 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 upstream.
+
+In 'hci_req_sync_complete()', always free the previous sync
+request state before assigning reference to a new one.
+
+Reported-by: syzbot+39ec16ff6cc18b1d066d@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=39ec16ff6cc18b1d066d
+Cc: stable@vger.kernel.org
+Fixes: f60cb30579d3 ("Bluetooth: Convert hci_req_sync family of function to new request API")
+Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_request.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/hci_request.c
++++ b/net/bluetooth/hci_request.c
+@@ -105,8 +105,10 @@ void hci_req_sync_complete(struct hci_de
+ if (hdev->req_status == HCI_REQ_PEND) {
+ hdev->req_result = result;
+ hdev->req_status = HCI_REQ_DONE;
+- if (skb)
++ if (skb) {
++ kfree_skb(hdev->req_skb);
+ hdev->req_skb = skb_get(skb);
++ }
+ wake_up_interruptible(&hdev->req_wait_q);
+ }
+ }
--- /dev/null
+From 31729e8c21ecfd671458e02b6511eb68c2225113 Mon Sep 17 00:00:00 2001
+From: Tim Huang <Tim.Huang@amd.com>
+Date: Wed, 27 Mar 2024 13:10:37 +0800
+Subject: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
+
+From: Tim Huang <Tim.Huang@amd.com>
+
+commit 31729e8c21ecfd671458e02b6511eb68c2225113 upstream.
+
+While doing multiple S4 stress tests, GC/RLC/PMFW get into
+an invalid state resulting into hard hangs.
+
+Adding a GFX reset as workaround just before sending the
+MP1_UNLOAD message avoids this failure.
+
+Signed-off-by: Tim Huang <Tim.Huang@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: Mario Limonciello <superm1@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
+@@ -222,8 +222,18 @@ static int smu_v13_0_4_system_features_c
+ struct amdgpu_device *adev = smu->adev;
+ int ret = 0;
+
+- if (!en && !adev->in_s0ix)
++ if (!en && !adev->in_s0ix) {
++ /* Adds a GFX reset as workaround just before sending the
++ * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering
++ * an invalid state.
++ */
++ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset,
++ SMU_RESET_MODE_2, NULL);
++ if (ret)
++ return ret;
++
+ ret = smu_cmn_send_smc_msg(smu, SMU_MSG_PrepareMp1ForUnload, NULL);
++ }
+
+ return ret;
+ }
--- /dev/null
+From ce5d241c3ad4568c12842168288993234345c0eb Mon Sep 17 00:00:00 2001
+From: Nini Song <nini.song@mediatek.com>
+Date: Thu, 25 Jan 2024 21:28:45 +0800
+Subject: media: cec: core: remove length check of Timer Status
+
+From: Nini Song <nini.song@mediatek.com>
+
+commit ce5d241c3ad4568c12842168288993234345c0eb upstream.
+
+The valid_la is used to check the length requirements,
+including special cases of Timer Status. If the length is
+shorter than 5, that means no Duration Available is returned,
+the message will be forced to be invalid.
+
+However, the description of Duration Available in the spec
+is that this parameter may be returned when these cases, or
+that it can be optionally return when these cases. The key
+words in the spec description are flexible choices.
+
+Remove the special length check of Timer Status to fit the
+spec which is not compulsory about that.
+
+Signed-off-by: Nini Song <nini.song@mediatek.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/cec/core/cec-adap.c | 14 --------------
+ 1 file changed, 14 deletions(-)
+
+--- a/drivers/media/cec/core/cec-adap.c
++++ b/drivers/media/cec/core/cec-adap.c
+@@ -1121,20 +1121,6 @@ void cec_received_msg_ts(struct cec_adap
+ if (valid_la && min_len) {
+ /* These messages have special length requirements */
+ switch (cmd) {
+- case CEC_MSG_TIMER_STATUS:
+- if (msg->msg[2] & 0x10) {
+- switch (msg->msg[2] & 0xf) {
+- case CEC_OP_PROG_INFO_NOT_ENOUGH_SPACE:
+- case CEC_OP_PROG_INFO_MIGHT_NOT_BE_ENOUGH_SPACE:
+- if (msg->len < 5)
+- valid_la = false;
+- break;
+- }
+- } else if ((msg->msg[2] & 0xf) == CEC_OP_PROG_ERROR_DUPLICATE) {
+- if (msg->len < 5)
+- valid_la = false;
+- }
+- break;
+ case CEC_MSG_RECORD_ON:
+ switch (msg->msg[2]) {
+ case CEC_OP_RECORD_SRC_OWN:
--- /dev/null
+From 3c89a068bfd0698a5478f4cf39493595ef757d5e Mon Sep 17 00:00:00 2001
+From: Anna-Maria Behnsen <anna-maria@linutronix.de>
+Date: Mon, 8 Apr 2024 09:02:23 +0200
+Subject: PM: s2idle: Make sure CPUs will wakeup directly on resume
+
+From: Anna-Maria Behnsen <anna-maria@linutronix.de>
+
+commit 3c89a068bfd0698a5478f4cf39493595ef757d5e upstream.
+
+s2idle works like a regular suspend with freezing processes and freezing
+devices. All CPUs except the control CPU go into idle. Once this is
+completed the control CPU kicks all other CPUs out of idle, so that they
+reenter the idle loop and then enter s2idle state. The control CPU then
+issues an swait() on the suspend state and therefore enters the idle loop
+as well.
+
+Due to being kicked out of idle, the other CPUs leave their NOHZ states,
+which means the tick is active and the corresponding hrtimer is programmed
+to the next jiffie.
+
+On entering s2idle the CPUs shut down their local clockevent device to
+prevent wakeups. The last CPU which enters s2idle shuts down its local
+clockevent and freezes timekeeping.
+
+On resume, one of the CPUs receives the wakeup interrupt, unfreezes
+timekeeping and its local clockevent and starts the resume process. At that
+point all other CPUs are still in s2idle with their clockevents switched
+off. They only resume when they are kicked by another CPU or after resuming
+devices and then receiving a device interrupt.
+
+That means there is no guarantee that all CPUs will wakeup directly on
+resume. As a consequence there is no guarantee that timers which are queued
+on those CPUs and should expire directly after resume, are handled. Also
+timer list timers which are remotely queued to one of those CPUs after
+resume will not result in a reprogramming IPI as the tick is
+active. Queueing a hrtimer will also not result in a reprogramming IPI
+because the first hrtimer event is already in the past.
+
+The recent introduction of the timer pull model (7ee988770326 ("timers:
+Implement the hierarchical pull model")) amplifies this problem, if the
+current migrator is one of the non woken up CPUs. When a non pinned timer
+list timer is queued and the queuing CPU goes idle, it relies on the still
+suspended migrator CPU to expire the timer which will happen by chance.
+
+The problem exists since commit 8d89835b0467 ("PM: suspend: Do not pause
+cpuidle in the suspend-to-idle path"). There the cpuidle_pause() call which
+in turn invoked a wakeup for all idle CPUs was moved to a later point in
+the resume process. This might not be reached or reached very late because
+it waits on a timer of a still suspended CPU.
+
+Address this by kicking all CPUs out of idle after the control CPU returns
+from swait() so that they resume their timers and restore consistent system
+state.
+
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218641
+Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
+Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Mario Limonciello <mario.limonciello@amd.com>
+Cc: 5.16+ <stable@kernel.org> # 5.16+
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/power/suspend.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/kernel/power/suspend.c
++++ b/kernel/power/suspend.c
+@@ -106,6 +106,12 @@ static void s2idle_enter(void)
+ swait_event_exclusive(s2idle_wait_head,
+ s2idle_state == S2IDLE_STATE_WAKE);
+
++ /*
++ * Kick all CPUs to ensure that they resume their timers and restore
++ * consistent system state.
++ */
++ wake_up_all_idle_cpus();
++
+ cpus_read_unlock();
+
+ raw_spin_lock_irq(&s2idle_lock);
--- /dev/null
+From ffe3986fece696cf65e0ef99e74c75f848be8e30 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Tue, 9 Apr 2024 15:13:09 -0400
+Subject: ring-buffer: Only update pages_touched when a new page is touched
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit ffe3986fece696cf65e0ef99e74c75f848be8e30 upstream.
+
+The "buffer_percent" logic that is used by the ring buffer splice code to
+only wake up the tasks when there's no data after the buffer is filled to
+the percentage of the "buffer_percent" file is dependent on three
+variables that determine the amount of data that is in the ring buffer:
+
+ 1) pages_read - incremented whenever a new sub-buffer is consumed
+ 2) pages_lost - incremented every time a writer overwrites a sub-buffer
+ 3) pages_touched - incremented when a write goes to a new sub-buffer
+
+The percentage is the calculation of:
+
+ (pages_touched - (pages_lost + pages_read)) / nr_pages
+
+Basically, the amount of data is the total number of sub-bufs that have been
+touched, minus the number of sub-bufs lost and sub-bufs consumed. This is
+divided by the total count to give the buffer percentage. When the
+percentage is greater than the value in the "buffer_percent" file, it
+wakes up splice readers waiting for that amount.
+
+It was observed that over time, the amount read from the splice was
+constantly decreasing the longer the trace was running. That is, if one
+asked for 60%, it would read over 60% when it first starts tracing, but
+then it would be woken up at under 60% and would slowly decrease the
+amount of data read after being woken up, where the amount becomes much
+less than the buffer percent.
+
+This was due to an accounting of the pages_touched incrementation. This
+value is incremented whenever a writer transfers to a new sub-buffer. But
+the place where it was incremented was incorrect. If a writer overflowed
+the current sub-buffer it would go to the next one. If it gets preempted
+by an interrupt at that time, and the interrupt performs a trace, it too
+will end up going to the next sub-buffer. But only one should increment
+the counter. Unfortunately, that was not the case.
+
+Change the cmpxchg() that does the real switch of the tail-page into a
+try_cmpxchg(), and on success, perform the increment of pages_touched. This
+will only increment the counter once for when the writer moves to a new
+sub-buffer, and not when there's a race and is incremented for when a
+writer and its preempting writer both move to the same new sub-buffer.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20240409151309.0d0e5056@gandalf.local.home
+
+Cc: stable@vger.kernel.org
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader")
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1543,7 +1543,6 @@ static void rb_tail_page_update(struct r
+ old_write = local_add_return(RB_WRITE_INTCNT, &next_page->write);
+ old_entries = local_add_return(RB_WRITE_INTCNT, &next_page->entries);
+
+- local_inc(&cpu_buffer->pages_touched);
+ /*
+ * Just make sure we have seen our old_write and synchronize
+ * with any interrupts that come in.
+@@ -1580,8 +1579,9 @@ static void rb_tail_page_update(struct r
+ */
+ local_set(&next_page->page->commit, 0);
+
+- /* Again, either we update tail_page or an interrupt does */
+- (void)cmpxchg(&cpu_buffer->tail_page, tail_page, next_page);
++ /* Either we update tail_page or an interrupt does */
++ if (try_cmpxchg(&cpu_buffer->tail_page, &tail_page, next_page))
++ local_inc(&cpu_buffer->pages_touched);
+ }
+ }
+
--- /dev/null
+smb3-fix-open-files-on-server-counter-going-negative.patch
+ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch
+batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch
+ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch
+bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch
+drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch
+pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch
+media-cec-core-remove-length-check-of-timer-status.patch
--- /dev/null
+From 28e0947651ce6a2200b9a7eceb93282e97d7e51a Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Sat, 6 Apr 2024 23:16:08 -0500
+Subject: smb3: fix Open files on server counter going negative
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 28e0947651ce6a2200b9a7eceb93282e97d7e51a upstream.
+
+We were decrementing the count of open files on server twice
+for the case where we were closing cached directories.
+
+Fixes: 8e843bf38f7b ("cifs: return a single-use cfid if we did not get a lease")
+Cc: stable@vger.kernel.org
+Acked-by: Bharath SM <bharathsm@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/cached_dir.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/smb/client/cached_dir.c
++++ b/fs/smb/client/cached_dir.c
+@@ -386,8 +386,8 @@ smb2_close_cached_fid(struct kref *ref)
+ if (cfid->is_open) {
+ rc = SMB2_close(0, cfid->tcon, cfid->fid.persistent_fid,
+ cfid->fid.volatile_fid);
+- if (rc != -EBUSY && rc != -EAGAIN)
+- atomic_dec(&cfid->tcon->num_remote_opens);
++ if (rc) /* should we retry on -EBUSY or -EAGAIN? */
++ cifs_dbg(VFS, "close cached dir rc %d\n", rc);
+ }
+
+ free_cached_dir(cfid);
projects / thirdparty / kernel / stable-queue.git / commitdiff
