--- /dev/null
+From ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 Mon Sep 17 00:00:00 2001
+From: Waiman Long <longman@redhat.com>
+Date: Tue, 11 Apr 2023 09:35:57 -0400
+Subject: cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Waiman Long <longman@redhat.com>
+
+commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream.
+
+After a successful cpuset_can_attach() call which increments the
+attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach()
+will be called later. In cpuset_attach(), tasks in cpuset_attach_wq,
+if present, will be woken up at the end. That is not the case in
+cpuset_cancel_attach(). So missed wakeup is possible if the attach
+operation is somehow cancelled. Fix that by doing the wakeup in
+cpuset_cancel_attach() as well.
+
+Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching")
+Signed-off-by: Waiman Long <longman@redhat.com>
+Reviewed-by: Michal Koutný <mkoutny@suse.com>
+Cc: stable@vger.kernel.org # v3.11+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cgroup/cpuset.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/cgroup/cpuset.c
++++ b/kernel/cgroup/cpuset.c
+@@ -2225,11 +2225,15 @@ out_unlock:
+ static void cpuset_cancel_attach(struct cgroup_taskset *tset)
+ {
+ struct cgroup_subsys_state *css;
++ struct cpuset *cs;
+
+ cgroup_taskset_first(tset, &css);
++ cs = css_cs(css);
+
+ percpu_down_write(&cpuset_rwsem);
+- css_cs(css)->attach_in_progress--;
++ cs->attach_in_progress--;
++ if (!cs->attach_in_progress)
++ wake_up(&cpuset_attach_wq);
+ percpu_up_write(&cpuset_rwsem);
+ }
+
--- /dev/null
+From d6a0443733434408f2cbd4c53fea6910599bab9e Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 11 Apr 2023 22:42:10 +0200
+Subject: mptcp: stricter state check in mptcp_worker
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit d6a0443733434408f2cbd4c53fea6910599bab9e upstream.
+
+As reported by Christoph, the mptcp protocol can run the
+worker when the relevant msk socket is in an unexpected state:
+
+connect()
+// incoming reset + fastclose
+// the mptcp worker is scheduled
+mptcp_disconnect()
+// msk is now CLOSED
+listen()
+mptcp_worker()
+
+Leading to the following splat:
+
+divide error: 0000 [#1] PREEMPT SMP
+CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
+Workqueue: events mptcp_worker
+RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018
+RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293
+RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000
+RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004
+RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000
+R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7
+R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ tcp_select_window net/ipv4/tcp_output.c:262 [inline]
+ __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345
+ tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]
+ tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459
+ mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]
+ mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705
+ process_one_work+0x3bd/0x950 kernel/workqueue.c:2390
+ worker_thread+0x5b/0x610 kernel/workqueue.c:2537
+ kthread+0x138/0x170 kernel/kthread.c:376
+ ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308
+ </TASK>
+
+This change addresses the issue explicitly checking for bad states
+before running the mptcp worker.
+
+Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
+Cc: stable@vger.kernel.org
+Reported-by: Christoph Paasch <cpaasch@apple.com>
+Link: https://github.com/multipath-tcp/mptcp_net-next/issues/374
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Tested-by: Christoph Paasch <cpaasch@apple.com>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -2448,7 +2448,7 @@ static void mptcp_worker(struct work_str
+
+ lock_sock(sk);
+ state = sk->sk_state;
+- if (unlikely(state == TCP_CLOSE))
++ if (unlikely((1 << state) & (TCPF_CLOSE | TCPF_LISTEN)))
+ goto unlock;
+
+ mptcp_check_data_fin_ack(sk);
--- /dev/null
+From a5cb752b125766524c921faab1a45cc96065b0a7 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 11 Apr 2023 22:42:09 +0200
+Subject: mptcp: use mptcp_schedule_work instead of open-coding it
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit a5cb752b125766524c921faab1a45cc96065b0a7 upstream.
+
+Beyond reducing code duplication this also avoids scheduling
+the mptcp_worker on a closed socket on some edge scenarios.
+
+The addressed issue is actually older than the blamed commit
+below, but this fix needs it as a pre-requisite.
+
+Fixes: ba8f48f7a4d7 ("mptcp: introduce mptcp_schedule_work")
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/options.c | 5 ++---
+ net/mptcp/subflow.c | 18 ++++++------------
+ 2 files changed, 8 insertions(+), 15 deletions(-)
+
+--- a/net/mptcp/options.c
++++ b/net/mptcp/options.c
+@@ -1156,9 +1156,8 @@ bool mptcp_incoming_options(struct sock
+ */
+ if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq) {
+ if (mp_opt.data_fin && mp_opt.data_len == 1 &&
+- mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64) &&
+- schedule_work(&msk->work))
+- sock_hold(subflow->conn);
++ mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
++ mptcp_schedule_work((struct sock *)msk);
+
+ return true;
+ }
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -360,9 +360,8 @@ void mptcp_subflow_reset(struct sock *ss
+
+ tcp_send_active_reset(ssk, GFP_ATOMIC);
+ tcp_done(ssk);
+- if (!test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &mptcp_sk(sk)->flags) &&
+- schedule_work(&mptcp_sk(sk)->work))
+- return; /* worker will put sk for us */
++ if (!test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &mptcp_sk(sk)->flags))
++ mptcp_schedule_work(sk);
+
+ sock_put(sk);
+ }
+@@ -1010,8 +1009,8 @@ static enum mapping_status get_mapping_s
+ skb_ext_del(skb, SKB_EXT_MPTCP);
+ return MAPPING_OK;
+ } else {
+- if (updated && schedule_work(&msk->work))
+- sock_hold((struct sock *)msk);
++ if (updated)
++ mptcp_schedule_work((struct sock *)msk);
+
+ return MAPPING_DATA_FIN;
+ }
+@@ -1114,17 +1113,12 @@ static void mptcp_subflow_discard_data(s
+ /* sched mptcp worker to remove the subflow if no more data is pending */
+ static void subflow_sched_work_if_closed(struct mptcp_sock *msk, struct sock *ssk)
+ {
+- struct sock *sk = (struct sock *)msk;
+-
+ if (likely(ssk->sk_state != TCP_CLOSE))
+ return;
+
+ if (skb_queue_empty(&ssk->sk_receive_queue) &&
+- !test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags)) {
+- sock_hold(sk);
+- if (!schedule_work(&msk->work))
+- sock_put(sk);
+- }
++ !test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags))
++ mptcp_schedule_work((struct sock *)msk);
+ }
+
+ static bool subflow_can_fallback(struct mptcp_subflow_context *subflow)
--- /dev/null
+From c8e22b7a1694bb8d025ea636816472739d859145 Mon Sep 17 00:00:00 2001
+From: Jiri Kosina <jkosina@suse.cz>
+Date: Tue, 4 Apr 2023 21:23:42 +0200
+Subject: scsi: ses: Handle enclosure with just a primary component gracefully
+
+From: Jiri Kosina <jkosina@suse.cz>
+
+commit c8e22b7a1694bb8d025ea636816472739d859145 upstream.
+
+This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure
+has no components") and introduces proper handling of case where there are
+no detected secondary components, but primary component (enumerated in
+num_enclosures) does exist. That fix was originally proposed by Ding Hui
+<dinghui@sangfor.com.cn>.
+
+Completely ignoring devices that have one primary enclosure and no
+secondary one results in ses_intf_add() bailing completely
+
+ scsi 2:0:0:254: enclosure has no enumerated components
+ scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such
+
+even on valid configurations with 1 primary and 0 secondary enclosures as
+below:
+
+ # sg_ses /dev/sg0
+ 3PARdata SES 3321
+ Supported diagnostic pages:
+ Supported Diagnostic Pages [sdp] [0x0]
+ Configuration (SES) [cf] [0x1]
+ Short Enclosure Status (SES) [ses] [0x8]
+ # sg_ses -p cf /dev/sg0
+ 3PARdata SES 3321
+ Configuration diagnostic page:
+ number of secondary subenclosures: 0
+ generation code: 0x0
+ enclosure descriptor list
+ Subenclosure identifier: 0 [primary]
+ relative ES process id: 0, number of ES processes: 1
+ number of type descriptor headers: 1
+ enclosure logical identifier (hex): 20000002ac02068d
+ enclosure vendor: 3PARdata product: VV rev: 3321
+ type descriptor header and text list
+ Element type: Unspecified, subenclosure id: 0
+ number of possible elements: 1
+
+The changelog for the original fix follows
+
+=====
+We can get a crash when disconnecting the iSCSI session,
+the call trace like this:
+
+ [ffff00002a00fb70] kfree at ffff00000830e224
+ [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4
+ [ffff00002a00fbd0] device_del at ffff0000086b6a98
+ [ffff00002a00fc50] device_unregister at ffff0000086b6d58
+ [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c
+ [ffff00002a00fca0] scsi_remove_device at ffff000008706134
+ [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4
+ [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0
+ [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4
+ [ffff00002a00fdb0] process_one_work at ffff00000810f35c
+ [ffff00002a00fe00] worker_thread at ffff00000810f648
+ [ffff00002a00fe70] kthread at ffff000008116e98
+
+In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,
+but not saved in edev->component[i].scratch
+
+In this situation, edev->component[0].scratch is an invalid pointer,
+when kfree it in ses_intf_remove_enclosure, a crash like above would happen
+The call trace also could be other random cases when kfree cannot catch
+the invalid pointer
+
+We should not use edev->component[] array when the components count is 0
+We also need check index when use edev->component[] array in
+ses_enclosure_data_process
+=====
+
+Reported-by: Michal Kolar <mich.k@seznam.cz>
+Originally-by: Ding Hui <dinghui@sangfor.com.cn>
+Cc: stable@vger.kernel.org
+Fixes: 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components")
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2304042122270.29760@cbobk.fhfr.pm
+Tested-by: Michal Kolar <mich.k@seznam.cz>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/ses.c | 20 ++++++++------------
+ 1 file changed, 8 insertions(+), 12 deletions(-)
+
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -503,9 +503,6 @@ static int ses_enclosure_find_by_addr(st
+ int i;
+ struct ses_component *scomp;
+
+- if (!edev->component[0].scratch)
+- return 0;
+-
+ for (i = 0; i < edev->components; i++) {
+ scomp = edev->component[i].scratch;
+ if (scomp->addr != efd->addr)
+@@ -596,8 +593,10 @@ static void ses_enclosure_data_process(s
+ components++,
+ type_ptr[0],
+ name);
+- else
++ else if (components < edev->components)
+ ecomp = &edev->component[components++];
++ else
++ ecomp = ERR_PTR(-EINVAL);
+
+ if (!IS_ERR(ecomp)) {
+ if (addl_desc_ptr) {
+@@ -728,11 +727,6 @@ static int ses_intf_add(struct device *c
+ components += type_ptr[1];
+ }
+
+- if (components == 0) {
+- sdev_printk(KERN_WARNING, sdev, "enclosure has no enumerated components\n");
+- goto err_free;
+- }
+-
+ ses_dev->page1 = buf;
+ ses_dev->page1_len = len;
+ buf = NULL;
+@@ -774,9 +768,11 @@ static int ses_intf_add(struct device *c
+ buf = NULL;
+ }
+ page2_not_supported:
+- scomp = kcalloc(components, sizeof(struct ses_component), GFP_KERNEL);
+- if (!scomp)
+- goto err_free;
++ if (components > 0) {
++ scomp = kcalloc(components, sizeof(struct ses_component), GFP_KERNEL);
++ if (!scomp)
++ goto err_free;
++ }
+
+ edev = enclosure_register(cdev->parent, dev_name(&sdev->sdev_gendev),
+ components, &ses_enclosure_callbacks);
net-sfp-initialize-sfp-i2c_block_size-at-sfp-allocation.patch
net-phy-nxp-c45-tja11xx-add-remove-callback.patch
net-phy-nxp-c45-tja11xx-fix-unsigned-long-multiplication-overflow.patch
+scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch
+x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch
+cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch
+mptcp-use-mptcp_schedule_work-instead-of-open-coding-it.patch
+mptcp-stricter-state-check-in-mptcp_worker.patch
--- /dev/null
+From f195fc1e9715ba826c3b62d58038f760f66a4fe9 Mon Sep 17 00:00:00 2001
+From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
+Date: Wed, 29 Mar 2023 22:58:59 +0530
+Subject: x86/PCI: Add quirk for AMD XHCI controller that loses MSI-X state in D3hot
+
+From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
+
+commit f195fc1e9715ba826c3b62d58038f760f66a4fe9 upstream.
+
+The AMD [1022:15b8] USB controller loses some internal functional MSI-X
+context when transitioning from D0 to D3hot. BIOS normally traps D0->D3hot
+and D3hot->D0 transitions so it can save and restore that internal context,
+but some firmware in the field can't do this because it fails to clear the
+AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit.
+
+Clear AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit before USB controller
+initialization during boot.
+
+Link: https://lore.kernel.org/linux-usb/Y%2Fz9GdHjPyF2rNG3@glanzmann.de/T/#u
+Link: https://lore.kernel.org/r/20230329172859.699743-1-Basavaraj.Natikar@amd.com
+Reported-by: Thomas Glanzmann <thomas@glanzmann.de>
+Tested-by: Thomas Glanzmann <thomas@glanzmann.de>
+Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/pci/fixup.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/arch/x86/pci/fixup.c
++++ b/arch/x86/pci/fixup.c
+@@ -7,6 +7,7 @@
+ #include <linux/dmi.h>
+ #include <linux/pci.h>
+ #include <linux/vgaarb.h>
++#include <asm/amd_nb.h>
+ #include <asm/hpet.h>
+ #include <asm/pci_x86.h>
+
+@@ -824,3 +825,23 @@ static void rs690_fix_64bit_dma(struct p
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7910, rs690_fix_64bit_dma);
+
+ #endif
++
++#ifdef CONFIG_AMD_NB
++
++#define AMD_15B8_RCC_DEV2_EPF0_STRAP2 0x10136008
++#define AMD_15B8_RCC_DEV2_EPF0_STRAP2_NO_SOFT_RESET_DEV2_F0_MASK 0x00000080L
++
++static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev)
++{
++ u32 data;
++
++ if (!amd_smn_read(0, AMD_15B8_RCC_DEV2_EPF0_STRAP2, &data)) {
++ data &= ~AMD_15B8_RCC_DEV2_EPF0_STRAP2_NO_SOFT_RESET_DEV2_F0_MASK;
++ if (amd_smn_write(0, AMD_15B8_RCC_DEV2_EPF0_STRAP2, data))
++ pci_err(dev, "Failed to write data 0x%x\n", data);
++ } else {
++ pci_err(dev, "Failed to read data\n");
++ }
++}
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0);
++#endif
projects / thirdparty / kernel / stable-queue.git / commitdiff
