--- /dev/null
+From 8893d27ffcaf6ec6267038a177cb87bcde4dd3de Mon Sep 17 00:00:00 2001
+From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
+Date: Fri, 4 Mar 2022 17:54:47 +0000
+Subject: crypto: qat - disable registration of algorithms
+
+From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
+
+commit 8893d27ffcaf6ec6267038a177cb87bcde4dd3de upstream.
+
+The implementations of aead and skcipher in the QAT driver do not
+support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
+If the HW queue is full, the driver returns -EBUSY but does not enqueue
+the request.
+This can result in applications like dm-crypt waiting indefinitely for a
+completion of a request that was never submitted to the hardware.
+
+To avoid this problem, disable the registration of all crypto algorithms
+in the QAT driver by setting the number of crypto instances to 0 at
+configuration time.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/qat/qat_common/qat_crypto.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/crypto/qat/qat_common/qat_crypto.c
++++ b/drivers/crypto/qat/qat_common/qat_crypto.c
+@@ -126,6 +126,14 @@ int qat_crypto_dev_config(struct adf_acc
+ goto err;
+ if (adf_cfg_section_add(accel_dev, "Accelerator0"))
+ goto err;
++
++ /* Temporarily set the number of crypto instances to zero to avoid
++ * registering the crypto algorithms.
++ * This will be removed when the algorithms will support the
++ * CRYPTO_TFM_REQ_MAY_BACKLOG flag
++ */
++ instances = 0;
++
+ for (i = 0; i < instances; i++) {
+ val = i;
+ snprintf(key, sizeof(key), ADF_CY "%d" ADF_RING_BANK_NUM, i);
--- /dev/null
+From 10c535787436d62ea28156a4b91365fd89b5a432 Mon Sep 17 00:00:00 2001
+From: "Paul E. McKenney" <paulmck@kernel.org>
+Date: Fri, 21 Jan 2022 12:40:08 -0800
+Subject: rcu: Don't deboost before reporting expedited quiescent state
+
+From: Paul E. McKenney <paulmck@kernel.org>
+
+commit 10c535787436d62ea28156a4b91365fd89b5a432 upstream.
+
+Currently rcu_preempt_deferred_qs_irqrestore() releases rnp->boost_mtx
+before reporting the expedited quiescent state. Under heavy real-time
+load, this can result in this function being preempted before the
+quiescent state is reported, which can in turn prevent the expedited grace
+period from completing. Tim Murray reports that the resulting expedited
+grace periods can take hundreds of milliseconds and even more than one
+second, when they should normally complete in less than a millisecond.
+
+This was fine given that there were no particular response-time
+constraints for synchronize_rcu_expedited(), as it was designed
+for throughput rather than latency. However, some users now need
+sub-100-millisecond response-time constratints.
+
+This patch therefore follows Neeraj's suggestion (seconded by Tim and
+by Uladzislau Rezki) of simply reversing the two operations.
+
+Reported-by: Tim Murray <timmurray@google.com>
+Reported-by: Joel Fernandes <joelaf@google.com>
+Reported-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
+Reviewed-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
+Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
+Tested-by: Tim Murray <timmurray@google.com>
+Cc: Todd Kjos <tkjos@google.com>
+Cc: Sandeep Patil <sspatil@google.com>
+Cc: <stable@vger.kernel.org> # 5.4.x
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/rcu/tree_plugin.h | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/kernel/rcu/tree_plugin.h
++++ b/kernel/rcu/tree_plugin.h
+@@ -531,16 +531,17 @@ rcu_preempt_deferred_qs_irqrestore(struc
+ raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+ }
+
+- /* Unboost if we were boosted. */
+- if (IS_ENABLED(CONFIG_RCU_BOOST) && drop_boost_mutex)
+- rt_mutex_futex_unlock(&rnp->boost_mtx);
+-
+ /*
+ * If this was the last task on the expedited lists,
+ * then we need to report up the rcu_node hierarchy.
+ */
+ if (!empty_exp && empty_exp_now)
+ rcu_report_exp_rnp(rnp, true);
++
++ /* Unboost if we were boosted. */
++ if (IS_ENABLED(CONFIG_RCU_BOOST) && drop_boost_mutex)
++ rt_mutex_futex_unlock(&rnp->boost_mtx);
++
+ } else {
+ local_irq_restore(flags);
+ }
--- /dev/null
+From 1ec7ed5163c70a0d040150d2279f932c7e7c143f Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Fri, 25 Feb 2022 11:44:32 +0200
+Subject: Revert "ath: add support for special 0x0 regulatory domain"
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f upstream.
+
+This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
+
+Users are reporting regressions in regulatory domain detection and
+channel availability.
+
+The problem this was trying to resolve was fixed in firmware anyway:
+
+ QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042
+ https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552
+
+Link: https://bbs.archlinux.org/viewtopic.php?id=254535
+Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html
+Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html
+Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/
+Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
+Cc: <stable@vger.kernel.org>
+Cc: Wen Gong <wgong@codeaurora.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
+Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/regd.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/ath/regd.c
++++ b/drivers/net/wireless/ath/regd.c
+@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulator
+
+ /*
+ * Some users have reported their EEPROM programmed with
+- * 0x8000 or 0x0 set, this is not a supported regulatory
+- * domain but since we have more than one user with it we
+- * need a solution for them. We default to 0x64, which is
+- * the default Atheros world regulatory domain.
++ * 0x8000 set, this is not a supported regulatory domain
++ * but since we have more than one user with it we need
++ * a solution for them. We default to 0x64, which is the
++ * default Atheros world regulatory domain.
+ */
+ static void ath_regd_sanitize(struct ath_regulatory *reg)
+ {
+- if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
++ if (reg->current_rd != COUNTRY_ERD_FLAG)
+ return;
+ printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
+ reg->current_rd = 0x64;
acpi-x86-work-around-broken-xsdt-on-advantech-dac-bj01-board.patch
acpi-battery-add-device-hid-and-quirk-for-microsoft-surface-go-3.patch
acpi-video-force-backlight-native-for-clevo-nl5xru-and-nl5xnu.patch
+crypto-qat-disable-registration-of-algorithms.patch
+revert-ath-add-support-for-special-0x0-regulatory-domain.patch
+rcu-don-t-deboost-before-reporting-expedited-quiescent-state.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
