--- /dev/null
+From f8f9ab2d98116e79d220f1d089df7464ad4e026d Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Fri, 3 Nov 2023 10:35:40 -0600
+Subject: io_uring/net: ensure socket is marked connected on connect retry
+
+From: Jens Axboe <axboe@kernel.dk>
+
+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 <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/net.c | 24 +++++++++++-------------
+ 1 file changed, 11 insertions(+), 13 deletions(-)
+
+--- a/io_uring/net.c
++++ b/io_uring/net.c
+@@ -1433,16 +1433,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 {
+@@ -1462,9 +1452,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;
+@@ -1478,6 +1466,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:
--- /dev/null
+From 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 Mon Sep 17 00:00:00 2001
+From: Dominique Martinet <dominique.martinet@atmark-techno.com>
+Date: Fri, 3 Nov 2023 09:42:20 +0900
+Subject: Revert "mmc: core: Capture correct oemid-bits for eMMC cards"
+
+From: Dominique Martinet <dominique.martinet@atmark-techno.com>
+
+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 <dominique.martinet@atmark-techno.com>
+Cc: stable@vger.kernel.org
+Cc: Alex Fetters <Alex.Fetters@garmin.com>
+Reviewed-by: Avri Altman <avri.altman@wdc.com>
+Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
fbdev-imsttfb-fix-a-resource-leak-in-probe.patch
fbdev-fsl-diu-fb-mark-wr_reg_wa-static.patch
tracing-kprobes-fix-the-order-of-argument-descriptio.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-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch
btrfs-use-u64-for-buffer-sizes-in-the-tree-search-io.patch
--- /dev/null
+From 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+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 <yazen.ghannam@amd.com>
+
+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 <yazen.ghannam@amd.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -100,6 +100,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) },
+ {}
+ };
projects / thirdparty / kernel / stable-queue.git / commitdiff
