--- /dev/null
+From 1a2a94a4392d5d1e5e25cc127573452f4c7fa9b8 Mon Sep 17 00:00:00 2001
+From: Nicolas MURE <nicolas.mure2019@gmail.com>
+Date: Mon, 1 Mar 2021 16:27:28 +0100
+Subject: ALSA: usb-audio: Configure Pioneer DJM-850 samplerate
+
+From: Nicolas MURE <nicolas.mure2019@gmail.com>
+
+commit 1a2a94a4392d5d1e5e25cc127573452f4c7fa9b8 upstream.
+
+Send an `URB_CONTROL out` USB frame to the device to configure its
+samplerate. This should be done before using the device for audio
+streaming (capture or playback).
+
+See https://github.com/nm2107/Pioneer-DJM-850-driver-reverse-engineering/blob/172fb9a61055960c88c67b7c416fe5bf3609807b/doc/windows-dvs/framerate-setting/README.md
+
+Signed-off-by: Nicolas MURE <nicolas.mure2019@gmail.com>
+Link: https://lore.kernel.org/r/20210301152729.18094-4-nicolas.mure2019@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1511,6 +1511,9 @@ void snd_usb_set_format_quirk(struct snd
+ case USB_ID(0x2b73, 0x0013): /* Pioneer DJM-450 */
+ pioneer_djm_set_format_quirk(subs, 0x0082);
+ break;
++ case USB_ID(0x08e4, 0x0163): /* Pioneer DJM-850 */
++ pioneer_djm_set_format_quirk(subs, 0x0086);
++ break;
+ }
+ }
+
--- /dev/null
+From e7df7df5a3809d733888db6ce6592a644acaac19 Mon Sep 17 00:00:00 2001
+From: Olivia Mackintosh <livvy@base.nu>
+Date: Sun, 18 Apr 2021 17:59:01 +0100
+Subject: ALSA: usb-audio: DJM-750: ensure format is set
+
+From: Olivia Mackintosh <livvy@base.nu>
+
+commit e7df7df5a3809d733888db6ce6592a644acaac19 upstream.
+
+Add case statement to set sample-rate for the DJM-750 Pioneer
+mixer. This was included as part of another patch but I think it has
+been archived on Patchwork and hasn't been merged.
+
+Signed-off-by: Olivia Mackintosh <livvy@base.nu>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210418165901.25776-1-livvy@base.nu
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1511,6 +1511,7 @@ void snd_usb_set_format_quirk(struct snd
+ case USB_ID(0x2b73, 0x0013): /* Pioneer DJM-450 */
+ pioneer_djm_set_format_quirk(subs, 0x0082);
+ break;
++ case USB_ID(0x08e4, 0x017f): /* Pioneer DJM-750 */
+ case USB_ID(0x08e4, 0x0163): /* Pioneer DJM-850 */
+ pioneer_djm_set_format_quirk(subs, 0x0086);
+ break;
--- /dev/null
+From 825619b09ad351894d2c6fb6705f5b3711d145c7 Mon Sep 17 00:00:00 2001
+From: Sagi Grimberg <sagi@grimberg.me>
+Date: Mon, 17 May 2021 14:07:45 -0700
+Subject: nvme-tcp: fix possible use-after-completion
+
+From: Sagi Grimberg <sagi@grimberg.me>
+
+commit 825619b09ad351894d2c6fb6705f5b3711d145c7 upstream.
+
+Commit db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq
+context") added a second context that may perform a network send.
+This means that now RX and TX are not serialized in nvme_tcp_io_work
+and can run concurrently.
+
+While there is correct mutual exclusion in the TX path (where
+the send_mutex protect the queue socket send activity) RX activity,
+and more specifically request completion may run concurrently.
+
+This means we must guarantee that any mutation of the request state
+related to its lifetime, bytes sent must not be accessed when a completion
+may have possibly arrived back (and processed).
+
+The race may trigger when a request completion arrives, processed
+_and_ reused as a fresh new request, exactly in the (relatively short)
+window between the last data payload sent and before the request iov_iter
+is advanced.
+
+Consider the following race:
+1. 16K write request is queued
+2. The nvme command and the data is sent to the controller (in-capsule
+ or solicited by r2t)
+3. After the last payload is sent but before the req.iter is advanced,
+ the controller sends back a completion.
+4. The completion is processed, the request is completed, and reused
+ to transfer a new request (write or read)
+5. The new request is queued, and the driver reset the request parameters
+ (nvme_tcp_setup_cmd_pdu).
+6. Now context in (2) resumes execution and advances the req.iter
+
+==> use-after-completion as this is already a new request.
+
+Fix this by making sure the request is not advanced after the last
+data payload send, knowing that a completion may have arrived already.
+
+An alternative solution would have been to delay the request completion
+or state change waiting for reference counting on the TX path, but besides
+adding atomic operations to the hot-path, it may present challenges in
+multi-stage R2T scenarios where a r2t handler needs to be deferred to
+an async execution.
+
+Reported-by: Narayan Ayalasomayajula <narayan.ayalasomayajula@wdc.com>
+Tested-by: Anil Mishra <anil.mishra@wdc.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Cc: stable@vger.kernel.org # v5.8+
+Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/tcp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/nvme/host/tcp.c
++++ b/drivers/nvme/host/tcp.c
+@@ -940,7 +940,6 @@ static int nvme_tcp_try_send_data(struct
+ if (ret <= 0)
+ return ret;
+
+- nvme_tcp_advance_req(req, ret);
+ if (queue->data_digest)
+ nvme_tcp_ddgst_update(queue->snd_hash, page,
+ offset, ret);
+@@ -957,6 +956,7 @@ static int nvme_tcp_try_send_data(struct
+ }
+ return 1;
+ }
++ nvme_tcp_advance_req(req, ret);
+ }
+ return -EAGAIN;
+ }
--- /dev/null
+From b09aaa3f2c0edeeed670cd29961a0e35bddc78cf Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Barnab=C3=A1s=20P=C5=91cze?= <pobrn@protonmail.com>
+Date: Fri, 7 May 2021 23:53:44 +0000
+Subject: platform/x86: ideapad-laptop: fix method name typo
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Barnabás Pőcze <pobrn@protonmail.com>
+
+commit b09aaa3f2c0edeeed670cd29961a0e35bddc78cf upstream.
+
+"smbc" should be "sbmc". `eval_smbc()` incorrectly called
+the SMBC ACPI method instead of SBMC. This resulted in
+partial loss of functionality. Rectify that by calling
+the correct ACPI method (SBMC), and also rename
+methods and constants.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212985
+Fixes: 0b765671cb80 ("platform/x86: ideapad-laptop: group and separate (un)related constants into enums")
+Fixes: ff36b0d953dc ("platform/x86: ideapad-laptop: rework and create new ACPI helpers")
+Cc: stable@vger.kernel.org # 5.12
+Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
+Link: https://lore.kernel.org/r/20210507235333.286505-1-pobrn@protonmail.com
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/ideapad-laptop.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/platform/x86/ideapad-laptop.c
++++ b/drivers/platform/x86/ideapad-laptop.c
+@@ -57,8 +57,8 @@ enum {
+ };
+
+ enum {
+- SMBC_CONSERVATION_ON = 3,
+- SMBC_CONSERVATION_OFF = 5,
++ SBMC_CONSERVATION_ON = 3,
++ SBMC_CONSERVATION_OFF = 5,
+ };
+
+ enum {
+@@ -182,9 +182,9 @@ static int eval_gbmd(acpi_handle handle,
+ return eval_int(handle, "GBMD", res);
+ }
+
+-static int exec_smbc(acpi_handle handle, unsigned long arg)
++static int exec_sbmc(acpi_handle handle, unsigned long arg)
+ {
+- return exec_simple_method(handle, "SMBC", arg);
++ return exec_simple_method(handle, "SBMC", arg);
+ }
+
+ static int eval_hals(acpi_handle handle, unsigned long *res)
+@@ -477,7 +477,7 @@ static ssize_t conservation_mode_store(s
+ if (err)
+ return err;
+
+- err = exec_smbc(priv->adev->handle, state ? SMBC_CONSERVATION_ON : SMBC_CONSERVATION_OFF);
++ err = exec_sbmc(priv->adev->handle, state ? SBMC_CONSERVATION_ON : SBMC_CONSERVATION_OFF);
+ if (err)
+ return err;
+
--- /dev/null
+From 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf Mon Sep 17 00:00:00 2001
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+Date: Mon, 3 May 2021 13:57:12 +0200
+Subject: rapidio: handle create_workqueue() failure
+
+From: Anirudh Rayabharam <mail@anirudhrb.com>
+
+commit 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf upstream.
+
+In case create_workqueue() fails, release all resources and return -ENOMEM
+to caller to avoid potential NULL pointer deref later. Move up the
+create_workequeue() call to return early and avoid unwinding the call to
+riocm_rx_fill().
+
+Cc: Alexandre Bounine <alex.bou9@gmail.com>
+Cc: Matt Porter <mporter@kernel.crashing.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
+Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rapidio/rio_cm.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/rapidio/rio_cm.c
++++ b/drivers/rapidio/rio_cm.c
+@@ -2127,6 +2127,14 @@ static int riocm_add_mport(struct device
+ return -ENODEV;
+ }
+
++ cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
++ if (!cm->rx_wq) {
++ rio_release_inb_mbox(mport, cmbox);
++ rio_release_outb_mbox(mport, cmbox);
++ kfree(cm);
++ return -ENOMEM;
++ }
++
+ /*
+ * Allocate and register inbound messaging buffers to be ready
+ * to receive channel and system management requests
+@@ -2137,7 +2145,6 @@ static int riocm_add_mport(struct device
+ cm->rx_slots = RIOCM_RX_RING_SIZE;
+ mutex_init(&cm->rx_lock);
+ riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
+- cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
+ INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
+
+ cm->tx_slot = 0;
--- /dev/null
+From 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Mon, 3 May 2021 13:57:11 +0200
+Subject: Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails"
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream.
+
+This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba.
+
+Because of recent interactions with developers from @umn.edu, all
+commits from them have been recently re-reviewed to ensure if they were
+correct or not.
+
+Upon review, this commit was found to be incorrect for the reasons
+below, so it must be reverted. It will be fixed up "correctly" in a
+later kernel change.
+
+The original commit has a memory leak on the error path here, it does
+not clean up everything properly.
+
+Cc: Kangjie Lu <kjlu@umn.edu>
+Cc: Alexandre Bounine <alex.bou9@gmail.com>
+Cc: Matt Porter <mporter@kernel.crashing.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Fixes: 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rapidio/rio_cm.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
+index 50ec53d67a4c..e6c16f04f2b4 100644
+--- a/drivers/rapidio/rio_cm.c
++++ b/drivers/rapidio/rio_cm.c
+@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device *dev,
+ mutex_init(&cm->rx_lock);
+ riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
+ cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
+- if (!cm->rx_wq) {
+- riocm_error("failed to allocate IBMBOX_%d on %s",
+- cmbox, mport->name);
+- rio_release_outb_mbox(mport, cmbox);
+- kfree(cm);
+- return -ENOMEM;
+- }
+-
+ INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
+
+ cm->tx_slot = 0;
+--
+2.31.1
+
--- /dev/null
+From 754f39158441f4c0d7a8255209dd9a939f08ce80 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Mon, 3 May 2021 13:56:32 +0200
+Subject: Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference"
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream.
+
+This reverts commit 32f47179833b63de72427131169809065db6745e.
+
+Because of recent interactions with developers from @umn.edu, all
+commits from them have been recently re-reviewed to ensure if they were
+correct or not.
+
+Upon review, this commit was found to be not be needed at all as the
+change was useless because this function can only be called when
+of_match_device matched on something. So it should be reverted.
+
+Cc: Aditya Pakki <pakki001@umn.edu>
+Cc: stable <stable@vger.kernel.org>
+Fixes: 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference")
+Acked-by: Jiri Slaby <jirislaby@kernel.org>
+Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/mvebu-uart.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/drivers/tty/serial/mvebu-uart.c
++++ b/drivers/tty/serial/mvebu-uart.c
+@@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platf
+ return -EINVAL;
+ }
+
+- if (!match)
+- return -ENODEV;
+-
+ /* Assume that all UART ports have a DT alias or none has */
+ id = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (!pdev->dev.of_node || id < 0)
alsa-hda-realtek-fix-silent-headphone-output-on-asus-ux430ua.patch
alsa-hda-realtek-add-fixup-for-hp-omen-laptop.patch
alsa-hda-realtek-add-fixup-for-hp-spectre-x360-15-df0xxx.patch
+alsa-usb-audio-configure-pioneer-djm-850-samplerate.patch
+alsa-usb-audio-djm-750-ensure-format-is-set.patch
+uio-uio_pci_generic-fix-return-value-changed-in-refactoring.patch
+uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch
+uio_hv_generic-fix-another-memory-leak-in-error-handling-paths.patch
+platform-x86-ideapad-laptop-fix-method-name-typo.patch
+revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch
+rapidio-handle-create_workqueue-failure.patch
+revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch
+nvme-tcp-fix-possible-use-after-completion.patch
+x86-build-fix-location-of-plugin-opt-flags.patch
+x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch
+x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch
+x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch
+x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch
+x86-sev-es-forward-page-faults-which-happen-during-emulation.patch
--- /dev/null
+From 156ed0215ef365604f2382d5164c36d3a1cfd98f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Martin=20=C3=85gren?= <martin.agren@gmail.com>
+Date: Thu, 22 Apr 2021 21:22:40 +0200
+Subject: uio/uio_pci_generic: fix return value changed in refactoring
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Martin Ågren <martin.agren@gmail.com>
+
+commit 156ed0215ef365604f2382d5164c36d3a1cfd98f upstream.
+
+Commit ef84928cff58 ("uio/uio_pci_generic: use device-managed function
+equivalents") was able to simplify various error paths thanks to no
+longer having to clean up on the way out. Some error paths were dropped,
+others were simplified. In one of those simplifications, the return
+value was accidentally changed from -ENODEV to -ENOMEM. Restore the old
+return value.
+
+Fixes: ef84928cff58 ("uio/uio_pci_generic: use device-managed function equivalents")
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Martin Ågren <martin.agren@gmail.com>
+Link: https://lore.kernel.org/r/20210422192240.1136373-1-martin.agren@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_pci_generic.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/uio/uio_pci_generic.c
++++ b/drivers/uio/uio_pci_generic.c
+@@ -82,7 +82,7 @@ static int probe(struct pci_dev *pdev,
+ }
+
+ if (pdev->irq && !pci_intx_mask_supported(pdev))
+- return -ENOMEM;
++ return -ENODEV;
+
+ gdev = devm_kzalloc(&pdev->dev, sizeof(struct uio_pci_generic_dev), GFP_KERNEL);
+ if (!gdev)
--- /dev/null
+From 3ee098f96b8b6c1a98f7f97915f8873164e6af9d Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 9 May 2021 09:13:03 +0200
+Subject: uio_hv_generic: Fix a memory leak in error handling paths
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream.
+
+If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be
+updated and 'hv_uio_cleanup()' in the error handling path will not be
+able to free the corresponding buffer.
+
+In such a case, we need to free the buffer explicitly.
+
+Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_hv_generic.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/uio/uio_hv_generic.c
++++ b/drivers/uio/uio_hv_generic.c
+@@ -296,8 +296,10 @@ hv_uio_probe(struct hv_device *dev,
+
+ ret = vmbus_establish_gpadl(channel, pdata->recv_buf,
+ RECV_BUFFER_SIZE, &pdata->recv_gpadl);
+- if (ret)
++ if (ret) {
++ vfree(pdata->recv_buf);
+ goto fail_close;
++ }
+
+ /* put Global Physical Address Label in name */
+ snprintf(pdata->recv_name, sizeof(pdata->recv_name),
+@@ -316,8 +318,10 @@ hv_uio_probe(struct hv_device *dev,
+
+ ret = vmbus_establish_gpadl(channel, pdata->send_buf,
+ SEND_BUFFER_SIZE, &pdata->send_gpadl);
+- if (ret)
++ if (ret) {
++ vfree(pdata->send_buf);
+ goto fail_close;
++ }
+
+ snprintf(pdata->send_name, sizeof(pdata->send_name),
+ "send:%u", pdata->send_gpadl);
--- /dev/null
+From 0b0226be3a52dadd965644bc52a807961c2c26df Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 9 May 2021 09:13:12 +0200
+Subject: uio_hv_generic: Fix another memory leak in error handling paths
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 0b0226be3a52dadd965644bc52a807961c2c26df upstream.
+
+Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
+function is never freed in the error handling path.
+
+Add the missing 'vmbus_free_ring()' call.
+
+Note that it is already freed in the .remove function.
+
+Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_hv_generic.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/uio/uio_hv_generic.c
++++ b/drivers/uio/uio_hv_generic.c
+@@ -291,7 +291,7 @@ hv_uio_probe(struct hv_device *dev,
+ pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE);
+ if (pdata->recv_buf == NULL) {
+ ret = -ENOMEM;
+- goto fail_close;
++ goto fail_free_ring;
+ }
+
+ ret = vmbus_establish_gpadl(channel, pdata->recv_buf,
+@@ -351,6 +351,8 @@ hv_uio_probe(struct hv_device *dev,
+
+ fail_close:
+ hv_uio_cleanup(dev, pdata);
++fail_free_ring:
++ vmbus_free_ring(dev->channel);
+
+ return ret;
+ }
--- /dev/null
+From 0024430e920f2900654ad83cd081cf52e02a3ef5 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Tue, 18 May 2021 12:01:06 -0700
+Subject: x86/build: Fix location of '-plugin-opt=' flags
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 0024430e920f2900654ad83cd081cf52e02a3ef5 upstream.
+
+Commit b33fff07e3e3 ("x86, build: allow LTO to be selected") added a
+couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model
+and stack alignment are not stored in LLVM bitcode.
+
+However, these flags were added to KBUILD_LDFLAGS prior to the
+emulation flag assignment, which uses ':=', so they were overwritten
+and never added to $(LD) invocations.
+
+The absence of these flags caused misalignment issues in the
+AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in
+general protection faults.
+
+Shuffle the assignment below the initial one so that the flags are
+properly passed along and all of the linker flags stay together.
+
+At the same time, avoid any future issues with clobbering flags by
+changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is
+already defined with ':=' in the main Makefile before being exported for
+modification here as a result of commit:
+
+ ce99d0bf312d ("kbuild: clear LDFLAGS in the top Makefile")
+
+Fixes: b33fff07e3e3 ("x86, build: allow LTO to be selected")
+Reported-by: Anthony Ruhier <aruhier@mailbox.org>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: Anthony Ruhier <aruhier@mailbox.org>
+Cc: stable@vger.kernel.org
+Link: https://github.com/ClangBuiltLinux/linux/issues/1374
+Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Makefile | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/Makefile
++++ b/arch/x86/Makefile
+@@ -170,11 +170,6 @@ ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
+ KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args,)
+ endif
+
+-ifdef CONFIG_LTO_CLANG
+-KBUILD_LDFLAGS += -plugin-opt=-code-model=kernel \
+- -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
+-endif
+-
+ # Workaround for a gcc prelease that unfortunately was shipped in a suse release
+ KBUILD_CFLAGS += -Wno-sign-compare
+ #
+@@ -194,7 +189,12 @@ ifdef CONFIG_RETPOLINE
+ endif
+ endif
+
+-KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE)
++KBUILD_LDFLAGS += -m elf_$(UTS_MACHINE)
++
++ifdef CONFIG_LTO_CLANG
++KBUILD_LDFLAGS += -plugin-opt=-code-model=kernel \
++ -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
++endif
+
+ ifdef CONFIG_X86_NEED_RELOCS
+ LDFLAGS_vmlinux := --emit-relocs --discard-none
--- /dev/null
+From b250f2f7792d15bcde98e0456781e2835556d5fa Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Wed, 19 May 2021 15:52:44 +0200
+Subject: x86/sev-es: Don't return NULL from sev_es_get_ghcb()
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit b250f2f7792d15bcde98e0456781e2835556d5fa upstream.
+
+sev_es_get_ghcb() is called from several places but only one of them
+checks the return value. The reaction to returning NULL is always the
+same: calling panic() and kill the machine.
+
+Instead of adding checks to all call sites, move the panic() into the
+function itself so that it will no longer return NULL.
+
+Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler")
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org # v5.10+
+Link: https://lkml.kernel.org/r/20210519135251.30093-2-joro@8bytes.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-es.c | 25 ++++++++++++-------------
+ 1 file changed, 12 insertions(+), 13 deletions(-)
+
+--- a/arch/x86/kernel/sev-es.c
++++ b/arch/x86/kernel/sev-es.c
+@@ -191,8 +191,18 @@ static __always_inline struct ghcb *sev_
+ if (unlikely(data->ghcb_active)) {
+ /* GHCB is already in use - save its contents */
+
+- if (unlikely(data->backup_ghcb_active))
+- return NULL;
++ if (unlikely(data->backup_ghcb_active)) {
++ /*
++ * Backup-GHCB is also already in use. There is no way
++ * to continue here so just kill the machine. To make
++ * panic() work, mark GHCBs inactive so that messages
++ * can be printed out.
++ */
++ data->ghcb_active = false;
++ data->backup_ghcb_active = false;
++
++ panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use");
++ }
+
+ /* Mark backup_ghcb active before writing to it */
+ data->backup_ghcb_active = true;
+@@ -1262,7 +1272,6 @@ static __always_inline bool on_vc_fallba
+ */
+ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication)
+ {
+- struct sev_es_runtime_data *data = this_cpu_read(runtime_data);
+ irqentry_state_t irq_state;
+ struct ghcb_state state;
+ struct es_em_ctxt ctxt;
+@@ -1288,16 +1297,6 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_co
+ */
+
+ ghcb = sev_es_get_ghcb(&state);
+- if (!ghcb) {
+- /*
+- * Mark GHCBs inactive so that panic() is able to print the
+- * message.
+- */
+- data->ghcb_active = false;
+- data->backup_ghcb_active = false;
+-
+- panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use");
+- }
+
+ vc_ghcb_invalidate(ghcb);
+ result = vc_init_em_ctxt(&ctxt, regs, error_code);
--- /dev/null
+From c25bbdb564060adaad5c3a8a10765c13487ba6a3 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Wed, 19 May 2021 15:52:45 +0200
+Subject: x86/sev-es: Forward page-faults which happen during emulation
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit c25bbdb564060adaad5c3a8a10765c13487ba6a3 upstream.
+
+When emulating guest instructions for MMIO or IOIO accesses, the #VC
+handler might get a page-fault and will not be able to complete. Forward
+the page-fault in this case to the correct handler instead of killing
+the machine.
+
+Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler")
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org # v5.10+
+Link: https://lkml.kernel.org/r/20210519135251.30093-3-joro@8bytes.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-es.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/kernel/sev-es.c
++++ b/arch/x86/kernel/sev-es.c
+@@ -1269,6 +1269,10 @@ static __always_inline void vc_forward_e
+ case X86_TRAP_UD:
+ exc_invalid_op(ctxt->regs);
+ break;
++ case X86_TRAP_PF:
++ write_cr2(ctxt->fi.cr2);
++ exc_page_fault(ctxt->regs, error_code);
++ break;
+ case X86_TRAP_AC:
+ exc_alignment_check(ctxt->regs, error_code);
+ break;
--- /dev/null
+From a50c5bebc99c525e7fbc059988c6a5ab8680cb76 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Mon, 17 May 2021 12:42:33 -0500
+Subject: x86/sev-es: Invalidate the GHCB after completing VMGEXIT
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+commit a50c5bebc99c525e7fbc059988c6a5ab8680cb76 upstream.
+
+Since the VMGEXIT instruction can be issued from userspace, invalidate
+the GHCB after performing VMGEXIT processing in the kernel.
+
+Invalidation is only required after userspace is available, so call
+vc_ghcb_invalidate() from sev_es_put_ghcb(). Update vc_ghcb_invalidate()
+to additionally clear the GHCB exit code so that it is always presented
+as 0 when VMGEXIT has been issued by anything else besides the kernel.
+
+Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler")
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-es-shared.c | 1 +
+ arch/x86/kernel/sev-es.c | 5 +++++
+ 2 files changed, 6 insertions(+)
+
+--- a/arch/x86/kernel/sev-es-shared.c
++++ b/arch/x86/kernel/sev-es-shared.c
+@@ -63,6 +63,7 @@ static bool sev_es_negotiate_protocol(vo
+
+ static __always_inline void vc_ghcb_invalidate(struct ghcb *ghcb)
+ {
++ ghcb->save.sw_exit_code = 0;
+ memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap));
+ }
+
+--- a/arch/x86/kernel/sev-es.c
++++ b/arch/x86/kernel/sev-es.c
+@@ -430,6 +430,11 @@ static __always_inline void sev_es_put_g
+ data->backup_ghcb_active = false;
+ state->ghcb = NULL;
+ } else {
++ /*
++ * Invalidate the GHCB so a VMGEXIT instruction issued
++ * from userspace won't appear to be valid.
++ */
++ vc_ghcb_invalidate(ghcb);
+ data->ghcb_active = false;
+ }
+ }
--- /dev/null
+From fea63d54f7a3e74f8ab489a8b82413a29849a594 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Mon, 17 May 2021 12:42:32 -0500
+Subject: x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+commit fea63d54f7a3e74f8ab489a8b82413a29849a594 upstream.
+
+Move the location of sev_es_put_ghcb() in preparation for an update to it
+in a follow-on patch. This will better highlight the changes being made
+to the function.
+
+No functional change.
+
+Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler")
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-es.c | 36 ++++++++++++++++++------------------
+ 1 file changed, 18 insertions(+), 18 deletions(-)
+
+--- a/arch/x86/kernel/sev-es.c
++++ b/arch/x86/kernel/sev-es.c
+@@ -209,24 +209,6 @@ static __always_inline struct ghcb *sev_
+ return ghcb;
+ }
+
+-static __always_inline void sev_es_put_ghcb(struct ghcb_state *state)
+-{
+- struct sev_es_runtime_data *data;
+- struct ghcb *ghcb;
+-
+- data = this_cpu_read(runtime_data);
+- ghcb = &data->ghcb_page;
+-
+- if (state->ghcb) {
+- /* Restore GHCB from Backup */
+- *ghcb = *state->ghcb;
+- data->backup_ghcb_active = false;
+- state->ghcb = NULL;
+- } else {
+- data->ghcb_active = false;
+- }
+-}
+-
+ /* Needed in vc_early_forward_exception */
+ void do_early_exception(struct pt_regs *regs, int trapnr);
+
+@@ -434,6 +416,24 @@ static enum es_result vc_slow_virt_to_ph
+ /* Include code shared with pre-decompression boot stage */
+ #include "sev-es-shared.c"
+
++static __always_inline void sev_es_put_ghcb(struct ghcb_state *state)
++{
++ struct sev_es_runtime_data *data;
++ struct ghcb *ghcb;
++
++ data = this_cpu_read(runtime_data);
++ ghcb = &data->ghcb_page;
++
++ if (state->ghcb) {
++ /* Restore GHCB from Backup */
++ *ghcb = *state->ghcb;
++ data->backup_ghcb_active = false;
++ state->ghcb = NULL;
++ } else {
++ data->ghcb_active = false;
++ }
++}
++
+ void noinstr __sev_es_nmi_complete(void)
+ {
+ struct ghcb_state state;
--- /dev/null
+From 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Wed, 19 May 2021 15:52:46 +0200
+Subject: x86/sev-es: Use __put_user()/__get_user() for data accesses
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream.
+
+The put_user() and get_user() functions do checks on the address which is
+passed to them. They check whether the address is actually a user-space
+address and whether its fine to access it. They also call might_fault()
+to indicate that they could fault and possibly sleep.
+
+All of these checks are neither wanted nor needed in the #VC exception
+handler, which can be invoked from almost any context and also for MMIO
+instructions from kernel space on kernel memory. All the #VC handler
+wants to know is whether a fault happened when the access was tried.
+
+This is provided by __put_user()/__get_user(), which just do the access
+no matter what. Also add comments explaining why __get_user() and
+__put_user() are the best choice here and why it is safe to use them
+in this context. Also explain why copy_to/from_user can't be used.
+
+In addition, also revert commit
+
+ 7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly")
+
+because using __get_user()/__put_user() fixes the same problem while
+the above commit introduced several problems:
+
+ 1) It uses access_ok() which is only allowed in task context.
+
+ 2) It uses memcpy() which has no fault handling at all and is
+ thus unsafe to use here.
+
+ [ bp: Fix up commit ID of the reverted commit above. ]
+
+Fixes: f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image")
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org # v5.10+
+Link: https://lkml.kernel.org/r/20210519135251.30093-4-joro@8bytes.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-es.c | 66 ++++++++++++++++++++++++++++++++---------------
+ 1 file changed, 46 insertions(+), 20 deletions(-)
+
+--- a/arch/x86/kernel/sev-es.c
++++ b/arch/x86/kernel/sev-es.c
+@@ -288,31 +288,44 @@ static enum es_result vc_write_mem(struc
+ u16 d2;
+ u8 d1;
+
+- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */
+- if (!user_mode(ctxt->regs) && !access_ok(target, size)) {
+- memcpy(dst, buf, size);
+- return ES_OK;
+- }
+-
++ /*
++ * This function uses __put_user() independent of whether kernel or user
++ * memory is accessed. This works fine because __put_user() does no
++ * sanity checks of the pointer being accessed. All that it does is
++ * to report when the access failed.
++ *
++ * Also, this function runs in atomic context, so __put_user() is not
++ * allowed to sleep. The page-fault handler detects that it is running
++ * in atomic context and will not try to take mmap_sem and handle the
++ * fault, so additional pagefault_enable()/disable() calls are not
++ * needed.
++ *
++ * The access can't be done via copy_to_user() here because
++ * vc_write_mem() must not use string instructions to access unsafe
++ * memory. The reason is that MOVS is emulated by the #VC handler by
++ * splitting the move up into a read and a write and taking a nested #VC
++ * exception on whatever of them is the MMIO access. Using string
++ * instructions here would cause infinite nesting.
++ */
+ switch (size) {
+ case 1:
+ memcpy(&d1, buf, 1);
+- if (put_user(d1, target))
++ if (__put_user(d1, target))
+ goto fault;
+ break;
+ case 2:
+ memcpy(&d2, buf, 2);
+- if (put_user(d2, target))
++ if (__put_user(d2, target))
+ goto fault;
+ break;
+ case 4:
+ memcpy(&d4, buf, 4);
+- if (put_user(d4, target))
++ if (__put_user(d4, target))
+ goto fault;
+ break;
+ case 8:
+ memcpy(&d8, buf, 8);
+- if (put_user(d8, target))
++ if (__put_user(d8, target))
+ goto fault;
+ break;
+ default:
+@@ -343,30 +356,43 @@ static enum es_result vc_read_mem(struct
+ u16 d2;
+ u8 d1;
+
+- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */
+- if (!user_mode(ctxt->regs) && !access_ok(s, size)) {
+- memcpy(buf, src, size);
+- return ES_OK;
+- }
+-
++ /*
++ * This function uses __get_user() independent of whether kernel or user
++ * memory is accessed. This works fine because __get_user() does no
++ * sanity checks of the pointer being accessed. All that it does is
++ * to report when the access failed.
++ *
++ * Also, this function runs in atomic context, so __get_user() is not
++ * allowed to sleep. The page-fault handler detects that it is running
++ * in atomic context and will not try to take mmap_sem and handle the
++ * fault, so additional pagefault_enable()/disable() calls are not
++ * needed.
++ *
++ * The access can't be done via copy_from_user() here because
++ * vc_read_mem() must not use string instructions to access unsafe
++ * memory. The reason is that MOVS is emulated by the #VC handler by
++ * splitting the move up into a read and a write and taking a nested #VC
++ * exception on whatever of them is the MMIO access. Using string
++ * instructions here would cause infinite nesting.
++ */
+ switch (size) {
+ case 1:
+- if (get_user(d1, s))
++ if (__get_user(d1, s))
+ goto fault;
+ memcpy(buf, &d1, 1);
+ break;
+ case 2:
+- if (get_user(d2, s))
++ if (__get_user(d2, s))
+ goto fault;
+ memcpy(buf, &d2, 2);
+ break;
+ case 4:
+- if (get_user(d4, s))
++ if (__get_user(d4, s))
+ goto fault;
+ memcpy(buf, &d4, 4);
+ break;
+ case 8:
+- if (get_user(d8, s))
++ if (__get_user(d8, s))
+ goto fault;
+ memcpy(buf, &d8, 8);
+ break;
projects / thirdparty / kernel / stable-queue.git / commitdiff
