From: Greg Kroah-Hartman Date: Wed, 15 Nov 2023 19:03:26 +0000 (-0500) Subject: 6.5-stable patches X-Git-Tag: v4.14.330~20 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=01b984ea698c2340f2c8b70b5e6e9a8c2d62f25e;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch revert-pci-aspm-disable-only-aspm_state_l1-when-driver-disables-l1.patch x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch --- diff --git a/queue-6.5/io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch b/queue-6.5/io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch new file mode 100644 index 00000000000..ce2bb65bb5c --- /dev/null +++ b/queue-6.5/io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch @@ -0,0 +1,95 @@ +From f8f9ab2d98116e79d220f1d089df7464ad4e026d Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Fri, 3 Nov 2023 10:35:40 -0600 +Subject: io_uring/net: ensure socket is marked connected on connect retry + +From: Jens Axboe + +commit f8f9ab2d98116e79d220f1d089df7464ad4e026d upstream. + +io_uring does non-blocking connection attempts, which can yield some +unexpected results if a connect request is re-attempted by an an +application. This is equivalent to the following sync syscall sequence: + +sock = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP); +connect(sock, &addr, sizeof(addr); + +ret == -1 and errno == EINPROGRESS expected here. Now poll for POLLOUT +on sock, and when that returns, we expect the socket to be connected. +But if we follow that procedure with: + +connect(sock, &addr, sizeof(addr)); + +you'd expect ret == -1 and errno == EISCONN here, but you actually get +ret == 0. If we attempt the connection one more time, then we get EISCON +as expected. + +io_uring used to do this, but turns out that bluetooth fails with EBADFD +if you attempt to re-connect. Also looks like EISCONN _could_ occur with +this sequence. + +Retain the ->in_progress logic, but work-around a potential EISCONN or +EBADFD error and only in those cases look at the sock_error(). This +should work in general and avoid the odd sequence of a repeated connect +request returning success when the socket is already connected. + +This is all a side effect of the socket state being in a CONNECTING +state when we get EINPROGRESS, and only a re-connect or other related +operation will turn that into CONNECTED. + +Cc: stable@vger.kernel.org +Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT") +Link: https://github.com/axboe/liburing/issues/980 +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/net.c | 24 +++++++++++------------- + 1 file changed, 11 insertions(+), 13 deletions(-) + +--- a/io_uring/net.c ++++ b/io_uring/net.c +@@ -1461,16 +1461,6 @@ int io_connect(struct io_kiocb *req, uns + int ret; + bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK; + +- if (connect->in_progress) { +- struct socket *socket; +- +- ret = -ENOTSOCK; +- socket = sock_from_file(req->file); +- if (socket) +- ret = sock_error(socket->sk); +- goto out; +- } +- + if (req_has_async_data(req)) { + io = req->async_data; + } else { +@@ -1490,9 +1480,7 @@ int io_connect(struct io_kiocb *req, uns + && force_nonblock) { + if (ret == -EINPROGRESS) { + connect->in_progress = true; +- return -EAGAIN; +- } +- if (ret == -ECONNABORTED) { ++ } else if (ret == -ECONNABORTED) { + if (connect->seen_econnaborted) + goto out; + connect->seen_econnaborted = true; +@@ -1506,6 +1494,16 @@ int io_connect(struct io_kiocb *req, uns + memcpy(req->async_data, &__io, sizeof(__io)); + return -EAGAIN; + } ++ if (connect->in_progress) { ++ /* ++ * At least bluetooth will return -EBADFD on a re-connect ++ * attempt, and it's (supposedly) also valid to get -EISCONN ++ * which means the previous result is good. For both of these, ++ * grab the sock_error() and use that for the completion. ++ */ ++ if (ret == -EBADFD || ret == -EISCONN) ++ ret = sock_error(sock_from_file(req->file)->sk); ++ } + if (ret == -ERESTARTSYS) + ret = -EINTR; + out: diff --git a/queue-6.5/revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch b/queue-6.5/revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch new file mode 100644 index 00000000000..219b6ed9366 --- /dev/null +++ b/queue-6.5/revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch @@ -0,0 +1,43 @@ +From 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 Mon Sep 17 00:00:00 2001 +From: Dominique Martinet +Date: Fri, 3 Nov 2023 09:42:20 +0900 +Subject: Revert "mmc: core: Capture correct oemid-bits for eMMC cards" + +From: Dominique Martinet + +commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream. + +This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff. + +The commit above made quirks with an OEMID fail to be applied, as they +were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP +macros but the field would only contain the bottom 8 bits. + +eMMC v5.1A might have bogus values in OEMID's higher bits so another fix +will be made, but it has been decided to revert this until that is ready. + +Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards") +Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org +Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com +Signed-off-by: Dominique Martinet +Cc: stable@vger.kernel.org +Cc: Alex Fetters +Reviewed-by: Avri Altman +Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/mmc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -104,7 +104,7 @@ static int mmc_decode_cid(struct mmc_car + case 3: /* MMC v3.1 - v3.3 */ + case 4: /* MMC v4 */ + card->cid.manfid = UNSTUFF_BITS(resp, 120, 8); +- card->cid.oemid = UNSTUFF_BITS(resp, 104, 8); ++ card->cid.oemid = UNSTUFF_BITS(resp, 104, 16); + card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8); + card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8); + card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8); diff --git a/queue-6.5/revert-pci-aspm-disable-only-aspm_state_l1-when-driver-disables-l1.patch b/queue-6.5/revert-pci-aspm-disable-only-aspm_state_l1-when-driver-disables-l1.patch new file mode 100644 index 00000000000..805da8a5dbf --- /dev/null +++ b/queue-6.5/revert-pci-aspm-disable-only-aspm_state_l1-when-driver-disables-l1.patch @@ -0,0 +1,74 @@ +From 3cb4f534bac010258b2688395c2f13459a932be9 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Wed, 11 Oct 2023 09:36:40 +0200 +Subject: Revert "PCI/ASPM: Disable only ASPM_STATE_L1 when driver, disables L1" + +From: Heiner Kallweit + +commit 3cb4f534bac010258b2688395c2f13459a932be9 upstream. + +This reverts commit fb097dcd5a28c0a2325632405c76a66777a6bed9. + +After fb097dcd5a28 ("PCI/ASPM: Disable only ASPM_STATE_L1 when driver +disables L1"), disabling L1 via pci_disable_link_state(PCIE_LINK_STATE_L1), +then enabling one substate, e.g., L1.1, via sysfs actually enables *all* +the substates. + +For example, r8169 disables L1 because of hardware issues on a number of +systems, which implicitly disables the L1.1 and L1.2 substates. + +On some systems, L1 and L1.1 work fine, but L1.2 causes missed rx packets. +Enabling L1.1 via the sysfs "aspm_l1_1" attribute unexpectedly enables L1.2 +as well as L1.1. + +After fb097dcd5a28, pci_disable_link_state(PCIE_LINK_STATE_L1) adds only +ASPM_L1 (but not any of the L1.x substates) to the "aspm_disable" mask: + + --- Before fb097dcd5a28 + +++ After fb097dcd5a28 + + # r8169 disables L1: + pci_disable_link_state(PCIE_LINK_STATE_L1) + - disable |= ASPM_L1 | ASPM_L1_1 | ASPM_L1_2 | ... # disable L1, L1.x + + disable |= ASPM_L1 # disable L1 only + + # write "1" to sysfs "aspm_l1_1" attribute: + l1_1_aspm + aspm_attr_store_common(state = ASPM_L1_1) + disable &= ~ASPM_L1_1 # enable L1.1 + if (state & (ASPM_L1_1 | ...)) # if enabling any substate + disable &= ~ASPM_L1 # enable L1 + + # final state: + - disable = ASPM_L1_2 | ... # L1, L1.1 enabled; L1.2 disabled + + disable = 0 # L1, L1.1, L1.2 all enabled + +Enabling an L1.x substate removes the substate and L1 from the +"aspm_disable" mask. After fb097dcd5a28, the substates were not added to +the mask when disabling L1, so enabling one substate implicitly enables all +of them. + +Revert fb097dcd5a28 so enabling one substate doesn't enable the others. + +Link: https://lore.kernel.org/r/c75931ac-7208-4200-9ca1-821629cf5e28@gmail.com +Signed-off-by: Heiner Kallweit +[bhelgaas: work through example in commit log] +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pcie/aspm.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/pcie/aspm.c ++++ b/drivers/pci/pcie/aspm.c +@@ -1059,7 +1059,8 @@ static int __pci_disable_link_state(stru + if (state & PCIE_LINK_STATE_L0S) + link->aspm_disable |= ASPM_STATE_L0S; + if (state & PCIE_LINK_STATE_L1) +- link->aspm_disable |= ASPM_STATE_L1; ++ /* L1 PM substates require L1 */ ++ link->aspm_disable |= ASPM_STATE_L1 | ASPM_STATE_L1SS; + if (state & PCIE_LINK_STATE_L1_1) + link->aspm_disable |= ASPM_STATE_L1_1; + if (state & PCIE_LINK_STATE_L1_2) diff --git a/queue-6.5/series b/queue-6.5/series index fc3f87d6793..b3d32b6441c 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -542,5 +542,9 @@ fbdev-fsl-diu-fb-mark-wr_reg_wa-static.patch tracing-kprobes-fix-the-order-of-argument-descriptio.patch revert-drm-ast-report-connection-status-on-display-p.patch selftests-mptcp-fix-wait_rm_addr-sf-parameters.patch +io_uring-net-ensure-socket-is-marked-connected-on-connect-retry.patch +x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch +revert-pci-aspm-disable-only-aspm_state_l1-when-driver-disables-l1.patch +revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch btrfs-use-u64-for-buffer-sizes-in-the-tree-search-io.patch btrfs-make-found_logical_ret-parameter-mandatory-for.patch diff --git a/queue-6.5/x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch b/queue-6.5/x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch new file mode 100644 index 00000000000..358fd2b5c0c --- /dev/null +++ b/queue-6.5/x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch @@ -0,0 +1,36 @@ +From 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Thu, 3 Aug 2023 10:04:30 -0500 +Subject: x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs + +From: Yazen Ghannam + +commit 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc upstream. + +Three PCI IDs for DF Function 4 were defined but not used. + +Add them to the "link" list. + +Fixes: f8faf3496633 ("x86/amd_nb: Add AMD PCI IDs for SMN communication") +Fixes: 23a5b8bb022c ("x86/amd_nb: Add PCI ID for family 19h model 78h") +Signed-off-by: Yazen Ghannam +Signed-off-by: Ingo Molnar +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/amd_nb.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kernel/amd_nb.c ++++ b/arch/x86/kernel/amd_nb.c +@@ -112,6 +112,9 @@ static const struct pci_device_id amd_nb + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M10H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F4) }, ++ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M60H_DF_F4) }, ++ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M70H_DF_F4) }, ++ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI200_DF_F4) },