--- /dev/null
+From 2e7b4a328ed6ea57d22853939e69bc86c560996d Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Wed, 19 Jan 2022 14:18:37 -0600
+Subject: Bluetooth: btusb: Add one more Bluetooth part for the Realtek RTL8852AE
+
+From: Larry Finger <Larry.Finger@lwfinger.net>
+
+commit 2e7b4a328ed6ea57d22853939e69bc86c560996d upstream.
+
+This Realtek device has both wifi and BT components. The latter reports
+a USB ID of 0bda:2852, which is not in the table.
+
+BT device description in /sys/kernel/debug/usb/devices contains the following entries:
+
+T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=0bda ProdID=2852 Rev= 0.00
+S: Manufacturer=Realtek
+S: Product=Bluetooth Radio
+S: SerialNumber=00e04c000001
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+The missing USB_ID was reported by user trius65 at https://github.com/lwfinger/rtw89/issues/122
+
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: stable@vger.kernel.org
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btusb.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -405,6 +405,8 @@ static const struct usb_device_id blackl
+ BTUSB_WIDEBAND_SPEECH },
+
+ /* Realtek 8852AE Bluetooth devices */
++ { USB_DEVICE(0x0bda, 0x2852), .driver_info = BTUSB_REALTEK |
++ BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0bda, 0xc852), .driver_info = BTUSB_REALTEK |
+ BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x0bda, 0x385a), .driver_info = BTUSB_REALTEK |
--- /dev/null
+From b3cf94c8b6b2f1a2b94825a025db291da2b151fd Mon Sep 17 00:00:00 2001
+From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+Date: Mon, 7 Mar 2022 21:04:45 +0100
+Subject: Bluetooth: btusb: Use quirk to skip HCI_FLT_CLEAR_ALL on fake CSR controllers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+
+commit b3cf94c8b6b2f1a2b94825a025db291da2b151fd upstream.
+
+Another subset of the more recent batch of Chinese clones aren't
+specs-compliant and seem to lock up whenever they receive a
+HCI_OP_SET_EVENT_FLT with flt_type set to zero/HCI_FLT_CLEAR_ALL,
+which on Linux (until the recent HCI state-machine refactor) happened
+right at BR/EDR setup. As there are other less-straightforward ways
+of reaching those operations, this patch is still relevant.
+
+So, while all the previous efforts to wrangle the herd of fake CSRs
+seem to be paying off (and these also get detected as such) we
+still need to take care of this quirk; testers seem to agree
+that these dongles tend to work well enough afterwards.
+
+From some cursory USB packet capture on Windows it seems like
+that driver doesn't appear to use this clear-all functionality at all.
+
+This patch was tested on some really popular AliExpress-style
+dongles, in my case marked as "V5.0". Chip markings: UG8413,
+the backside of the PCB says "USB Dangel" (sic).
+
+Here is the `hciconfig -a` output; for completeness:
+
+hci0: Type: Primary Bus: USB
+ BD Address: 00:1A:7D:DA:7X:XX ACL MTU: 679:8 SCO MTU: 48:16
+ UP RUNNING PSCAN ISCAN
+ Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7
+ Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
+ Link policy: RSWITCH SNIFF
+ Link mode: PERIPHERAL ACCEPT
+ Name: 'CSR8510 A10.'
+ Class: 0x7c0104
+ Service Classes: Rendering, Capturing, Object Transfer, Audio, Telephony
+ Device Class: Computer, Desktop workstation
+ HCI Version: 4.0 (0x6) Revision: 0x3120
+ LMP Version: 4.0 (0x6) Subversion: 0x22bb
+ Manufacturer: Cambridge Silicon Radio (10)
+
+As well as the `lsusb -vv -d 0a12:0001`:
+
+ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
+Device Descriptor:
+ bLength 18
+ bDescriptorType 1
+ bcdUSB 2.00
+ bDeviceClass 224 Wireless
+ bDeviceSubClass 1 Radio Frequency
+ bDeviceProtocol 1 Bluetooth
+ bMaxPacketSize0 64
+ idVendor 0x0a12 Cambridge Silicon Radio, Ltd
+ idProduct 0x0001 Bluetooth Dongle (HCI mode)
+ bcdDevice 88.91
+ iManufacturer 0
+ iProduct 2 BT DONGLE10
+ iSerial 0
+ bNumConfigurations 1
+
+Also, changed the benign dmesg print that shows up whenever the
+generic force-suspend fails from bt_dev_err to bt_dev_warn;
+it's okay and done on a best-effort basis, not a problem
+if that does not work.
+
+Also, swapped the HCI subver and LMP subver numbers for the Barrot
+in the comment, which I copied wrong the last time around.
+
+Fixes: 81cac64ba258a ("Bluetooth: Deal with USB devices that are faking CSR vendor")
+Fixes: cde1a8a992875 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers")
+Fixes: d74e0ae7e0303 ("Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134")
+Fixes: 0671c0662383e ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers")
+Fixes: f4292e2faf522 ("Bluetooth: btusb: Make the CSR clone chip force-suspend workaround more generic")
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=60824
+Link: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07
+
+Cc: stable@vger.kernel.org
+Cc: Hans de Goede <hdegoede@redhat.com>
+Tested-by: Gonzalo Tornaría <tornaria@cmat.edu.uy>
+Tested-by: Mateus Lemos <lemonsmateus@gmail.com>
+Tested-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/btusb.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -2045,6 +2045,8 @@ static int btusb_setup_csr(struct hci_de
+ */
+ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
+ set_bit(HCI_QUIRK_BROKEN_ERR_DATA_REPORTING, &hdev->quirks);
++ set_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks);
++ set_bit(HCI_QUIRK_NO_SUSPEND_NOTIFIER, &hdev->quirks);
+
+ /* Clear the reset quirk since this is not an actual
+ * early Bluetooth 1.1 device from CSR.
+@@ -2055,7 +2057,7 @@ static int btusb_setup_csr(struct hci_de
+ /*
+ * Special workaround for these BT 4.0 chip clones, and potentially more:
+ *
+- * - 0x0134: a Barrot 8041a02 (HCI rev: 0x1012 sub: 0x0810)
++ * - 0x0134: a Barrot 8041a02 (HCI rev: 0x0810 sub: 0x1012)
+ * - 0x7558: IC markings FR3191AHAL 749H15143 (HCI rev/sub-version: 0x0709)
+ *
+ * These controllers are really messed-up.
+@@ -2084,7 +2086,7 @@ static int btusb_setup_csr(struct hci_de
+ if (ret >= 0)
+ msleep(200);
+ else
+- bt_dev_err(hdev, "CSR: Failed to suspend the device for our Barrot 8041a02 receive-issue workaround");
++ bt_dev_warn(hdev, "CSR: Couldn't suspend the device for our Barrot 8041a02 receive-issue workaround");
+
+ pm_runtime_forbid(&data->udev->dev);
+
--- /dev/null
+From 0eaecfb2e4814d51ab172df3823e35d7c488b6d2 Mon Sep 17 00:00:00 2001
+From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+Date: Mon, 7 Mar 2022 21:04:44 +0100
+Subject: Bluetooth: hci_sync: Add a new quirk to skip HCI_FLT_CLEAR_ALL
+
+From: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+
+commit 0eaecfb2e4814d51ab172df3823e35d7c488b6d2 upstream.
+
+Some controllers have problems with being sent a command to clear
+all filtering. While the HCI code does not unconditionally
+send a clear-all anymore at BR/EDR setup (after the state machine
+refactor), there might be more ways of hitting these codepaths
+in the future as the kernel develops.
+
+Cc: stable@vger.kernel.org
+Cc: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/bluetooth/hci.h | 10 ++++++++++
+ net/bluetooth/hci_sync.c | 16 ++++++++++++++++
+ 2 files changed, 26 insertions(+)
+
+--- a/include/net/bluetooth/hci.h
++++ b/include/net/bluetooth/hci.h
+@@ -255,6 +255,16 @@ enum {
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER,
++
++ /* When this quirk is set, HCI_OP_SET_EVENT_FLT requests with
++ * HCI_FLT_CLEAR_ALL are ignored and event filtering is
++ * completely avoided. A subset of the CSR controller
++ * clones struggle with this and instantly lock up.
++ *
++ * Note that devices using this must (separately) disable
++ * runtime suspend, because event filtering takes place there.
++ */
++ HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL,
+ };
+
+ /* HCI device flags */
+--- a/net/bluetooth/hci_sync.c
++++ b/net/bluetooth/hci_sync.c
+@@ -2806,6 +2806,9 @@ static int hci_set_event_filter_sync(str
+ if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
+ return 0;
+
++ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
++ return 0;
++
+ memset(&cp, 0, sizeof(cp));
+ cp.flt_type = flt_type;
+
+@@ -2826,6 +2829,13 @@ static int hci_clear_event_filter_sync(s
+ if (!hci_dev_test_flag(hdev, HCI_EVENT_FILTER_CONFIGURED))
+ return 0;
+
++ /* In theory the state machine should not reach here unless
++ * a hci_set_event_filter_sync() call succeeds, but we do
++ * the check both for parity and as a future reminder.
++ */
++ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
++ return 0;
++
+ return hci_set_event_filter_sync(hdev, HCI_FLT_CLEAR_ALL, 0x00,
+ BDADDR_ANY, 0x00);
+ }
+@@ -4825,6 +4835,12 @@ static int hci_update_event_filter_sync(
+ if (!hci_dev_test_flag(hdev, HCI_BREDR_ENABLED))
+ return 0;
+
++ /* Some fake CSR controllers lock up after setting this type of
++ * filter, so avoid sending the request altogether.
++ */
++ if (test_bit(HCI_QUIRK_BROKEN_FILTER_CLEAR_ALL, &hdev->quirks))
++ return 0;
++
+ /* Always clear event filter when starting */
+ hci_clear_event_filter_sync(hdev);
+
--- /dev/null
+From 6b79f96f4a23846516e5e6e4dd37fc06f43a60dd Mon Sep 17 00:00:00 2001
+From: Roberto Sassu <roberto.sassu@huawei.com>
+Date: Mon, 13 Dec 2021 19:31:22 +0100
+Subject: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free()
+
+From: Roberto Sassu <roberto.sassu@huawei.com>
+
+commit 6b79f96f4a23846516e5e6e4dd37fc06f43a60dd upstream.
+
+If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it
+happened in the bug report by syzbot), virtio_gpu_array_put_free() could be
+called with objs equal to NULL.
+
+Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise
+return from the function.
+
+Cc: stable@vger.kernel.org # 5.13.x
+Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
+Reported-by: syzbot+e9072e90624a31dfa85f@syzkaller.appspotmail.com
+Fixes: 377f8331d0565 ("drm/virtio: fix possible leak/unlock virtio_gpu_object_array")
+Link: http://patchwork.freedesktop.org/patch/msgid/20211213183122.838119-1-roberto.sassu@huawei.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
++++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
+@@ -248,6 +248,9 @@ void virtio_gpu_array_put_free(struct vi
+ {
+ u32 i;
+
++ if (!objs)
++ return;
++
+ for (i = 0; i < objs->nents; i++)
+ drm_gem_object_put(objs->objs[i]);
+ virtio_gpu_array_free(objs);
--- /dev/null
+From cc16eecae687912238ee6efbff71ad31e2bc414e Mon Sep 17 00:00:00 2001
+From: Ritesh Harjani <riteshh@linux.ibm.com>
+Date: Thu, 10 Feb 2022 21:07:11 +0530
+Subject: jbd2: fix use-after-free of transaction_t race
+
+From: Ritesh Harjani <riteshh@linux.ibm.com>
+
+commit cc16eecae687912238ee6efbff71ad31e2bc414e upstream.
+
+jbd2_journal_wait_updates() is called with j_state_lock held. But if
+there is a commit in progress, then this transaction might get committed
+and freed via jbd2_journal_commit_transaction() ->
+jbd2_journal_free_transaction(), when we release j_state_lock.
+So check for journal->j_running_transaction everytime we release and
+acquire j_state_lock to avoid use-after-free issue.
+
+Link: https://lore.kernel.org/r/948c2fed518ae739db6a8f7f83f1d58b504f87d0.1644497105.git.ritesh.list@gmail.com
+Fixes: 4f98186848707f53 ("jbd2: refactor wait logic for transaction updates into a common function")
+Cc: stable@kernel.org
+Reported-and-tested-by: syzbot+afa2ca5171d93e44b348@syzkaller.appspotmail.com
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/transaction.c | 41 +++++++++++++++++++++++++----------------
+ 1 file changed, 25 insertions(+), 16 deletions(-)
+
+--- a/fs/jbd2/transaction.c
++++ b/fs/jbd2/transaction.c
+@@ -842,27 +842,38 @@ EXPORT_SYMBOL(jbd2_journal_restart);
+ */
+ void jbd2_journal_wait_updates(journal_t *journal)
+ {
+- transaction_t *commit_transaction = journal->j_running_transaction;
++ DEFINE_WAIT(wait);
+
+- if (!commit_transaction)
+- return;
++ while (1) {
++ /*
++ * Note that the running transaction can get freed under us if
++ * this transaction is getting committed in
++ * jbd2_journal_commit_transaction() ->
++ * jbd2_journal_free_transaction(). This can only happen when we
++ * release j_state_lock -> schedule() -> acquire j_state_lock.
++ * Hence we should everytime retrieve new j_running_transaction
++ * value (after j_state_lock release acquire cycle), else it may
++ * lead to use-after-free of old freed transaction.
++ */
++ transaction_t *transaction = journal->j_running_transaction;
+
+- spin_lock(&commit_transaction->t_handle_lock);
+- while (atomic_read(&commit_transaction->t_updates)) {
+- DEFINE_WAIT(wait);
++ if (!transaction)
++ break;
+
++ spin_lock(&transaction->t_handle_lock);
+ prepare_to_wait(&journal->j_wait_updates, &wait,
+- TASK_UNINTERRUPTIBLE);
+- if (atomic_read(&commit_transaction->t_updates)) {
+- spin_unlock(&commit_transaction->t_handle_lock);
+- write_unlock(&journal->j_state_lock);
+- schedule();
+- write_lock(&journal->j_state_lock);
+- spin_lock(&commit_transaction->t_handle_lock);
++ TASK_UNINTERRUPTIBLE);
++ if (!atomic_read(&transaction->t_updates)) {
++ spin_unlock(&transaction->t_handle_lock);
++ finish_wait(&journal->j_wait_updates, &wait);
++ break;
+ }
++ spin_unlock(&transaction->t_handle_lock);
++ write_unlock(&journal->j_state_lock);
++ schedule();
+ finish_wait(&journal->j_wait_updates, &wait);
++ write_lock(&journal->j_state_lock);
+ }
+- spin_unlock(&commit_transaction->t_handle_lock);
+ }
+
+ /**
+@@ -877,8 +888,6 @@ void jbd2_journal_wait_updates(journal_t
+ */
+ void jbd2_journal_lock_updates(journal_t *journal)
+ {
+- DEFINE_WAIT(wait);
+-
+ jbd2_might_wait_for_commit(journal);
+
+ write_lock(&journal->j_state_lock);
--- /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 | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/kernel/rcu/tree_plugin.h
++++ b/kernel/rcu/tree_plugin.h
+@@ -556,16 +556,16 @@ 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.rtmutex);
+-
+ /*
+ * 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.rtmutex);
+ } 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
+@@ -667,14 +667,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-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
+bluetooth-btusb-add-one-more-bluetooth-part-for-the-realtek-rtl8852ae.patch
+bluetooth-hci_sync-add-a-new-quirk-to-skip-hci_flt_clear_all.patch
+bluetooth-btusb-use-quirk-to-skip-hci_flt_clear_all-on-fake-csr-controllers.patch
+revert-ath-add-support-for-special-0x0-regulatory-domain.patch
+drm-virtio-ensure-that-objs-is-not-null-in-virtio_gpu_array_put_free.patch
+jbd2-fix-use-after-free-of-transaction_t-race.patch
+rcu-don-t-deboost-before-reporting-expedited-quiescent-state.patch
+uaccess-fix-integer-overflow-on-access_ok.patch
--- /dev/null
+From 222ca305c9fd39e5ed8104da25c09b2b79a516a8 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 10 Feb 2022 16:24:30 +0100
+Subject: uaccess: fix integer overflow on access_ok()
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 222ca305c9fd39e5ed8104da25c09b2b79a516a8 upstream.
+
+Three architectures check the end of a user access against the
+address limit without taking a possible overflow into account.
+Passing a negative length or another overflow in here returns
+success when it should not.
+
+Use the most common correct implementation here, which optimizes
+for a constant 'size' argument, and turns the common case into a
+single comparison.
+
+Cc: stable@vger.kernel.org
+Fixes: da551281947c ("csky: User access")
+Fixes: f663b60f5215 ("microblaze: Fix uaccess_ok macro")
+Fixes: 7567746e1c0d ("Hexagon: Add user access functions")
+Reported-by: David Laight <David.Laight@aculab.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/csky/include/asm/uaccess.h | 7 +++----
+ arch/hexagon/include/asm/uaccess.h | 18 +++++++++---------
+ arch/microblaze/include/asm/uaccess.h | 19 ++++---------------
+ 3 files changed, 16 insertions(+), 28 deletions(-)
+
+--- a/arch/csky/include/asm/uaccess.h
++++ b/arch/csky/include/asm/uaccess.h
+@@ -3,14 +3,13 @@
+ #ifndef __ASM_CSKY_UACCESS_H
+ #define __ASM_CSKY_UACCESS_H
+
+-#define user_addr_max() \
+- (uaccess_kernel() ? KERNEL_DS.seg : get_fs().seg)
++#define user_addr_max() (current_thread_info()->addr_limit.seg)
+
+ static inline int __access_ok(unsigned long addr, unsigned long size)
+ {
+- unsigned long limit = current_thread_info()->addr_limit.seg;
++ unsigned long limit = user_addr_max();
+
+- return ((addr < limit) && ((addr + size) < limit));
++ return (size <= limit) && (addr <= (limit - size));
+ }
+ #define __access_ok __access_ok
+
+--- a/arch/hexagon/include/asm/uaccess.h
++++ b/arch/hexagon/include/asm/uaccess.h
+@@ -25,17 +25,17 @@
+ * Returns true (nonzero) if the memory block *may* be valid, false (zero)
+ * if it is definitely invalid.
+ *
+- * User address space in Hexagon, like x86, goes to 0xbfffffff, so the
+- * simple MSB-based tests used by MIPS won't work. Some further
+- * optimization is probably possible here, but for now, keep it
+- * reasonably simple and not *too* slow. After all, we've got the
+- * MMU for backup.
+ */
++#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
++#define user_addr_max() (uaccess_kernel() ? ~0UL : TASK_SIZE)
+
+-#define __access_ok(addr, size) \
+- ((get_fs().seg == KERNEL_DS.seg) || \
+- (((unsigned long)addr < get_fs().seg) && \
+- (unsigned long)size < (get_fs().seg - (unsigned long)addr)))
++static inline int __access_ok(unsigned long addr, unsigned long size)
++{
++ unsigned long limit = TASK_SIZE;
++
++ return (size <= limit) && (addr <= (limit - size));
++}
++#define __access_ok __access_ok
+
+ /*
+ * When a kernel-mode page fault is taken, the faulting instruction
+--- a/arch/microblaze/include/asm/uaccess.h
++++ b/arch/microblaze/include/asm/uaccess.h
+@@ -39,24 +39,13 @@
+
+ # define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
+
+-static inline int access_ok(const void __user *addr, unsigned long size)
++static inline int __access_ok(unsigned long addr, unsigned long size)
+ {
+- if (!size)
+- goto ok;
++ unsigned long limit = user_addr_max();
+
+- if ((get_fs().seg < ((unsigned long)addr)) ||
+- (get_fs().seg < ((unsigned long)addr + size - 1))) {
+- pr_devel("ACCESS fail at 0x%08x (size 0x%x), seg 0x%08x\n",
+- (__force u32)addr, (u32)size,
+- (u32)get_fs().seg);
+- return 0;
+- }
+-ok:
+- pr_devel("ACCESS OK at 0x%08x (size 0x%x), seg 0x%08x\n",
+- (__force u32)addr, (u32)size,
+- (u32)get_fs().seg);
+- return 1;
++ return (size <= limit) && (addr <= (limit - size));
+ }
++#define access_ok(addr, size) __access_ok((unsigned long)addr, size)
+
+ # define __FIXUP_SECTION ".section .fixup,\"ax\"\n"
+ # define __EX_TABLE_SECTION ".section __ex_table,\"a\"\n"
projects / thirdparty / kernel / stable-queue.git / commitdiff
