From: Greg Kroah-Hartman Date: Fri, 3 Jun 2022 16:13:26 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.9.317~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=11cee8f4d9c1a029a583bb132340602dc2e74763;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm-dts-s5pv210-correct-interrupt-name-for-bluetooth-in-aries.patch bluetooth-hci_qca-use-del_timer_sync-before-freeing.patch crypto-caam-fix-i.mx6sx-entropy-delay-value.patch crypto-drbg-make-reseeding-from-get_random_bytes-synchronous.patch crypto-drbg-move-dynamic-reseed_threshold-adjustments-to-__drbg_seed.patch crypto-drbg-prepare-for-more-fine-grained-tracking-of-seeding-state.patch crypto-drbg-track-whether-drbg-was-seeded-with-rng_is_initialized.patch crypto-ecrdsa-fix-incorrect-use-of-vli_cmp.patch dm-crypt-make-printing-of-the-key-constant-time.patch dm-integrity-fix-error-code-in-dm_integrity_ctr.patch dm-stats-add-cond_resched-when-looping-over-entries.patch dm-verity-set-dm_target_immutable-feature-flag.patch drm-i915-fix-wstringop-overflow-warning-in-call-to-intel_read_wm_latency.patch exfat-check-if-cluster-num-is-valid.patch exfat-fix-referencing-wrong-parent-directory-information-after-renaming.patch hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch hid-multitouch-add-support-for-google-whiskers-touchpad.patch kvm-ppc-book3s-hv-fix-incorrect-null-check-on-list-iterator.patch kvm-x86-avoid-calling-x86-emulator-without-a-decoded-instruction.patch lib-crypto-add-prompts-back-to-crypto-libraries.patch net-ipa-compute-proper-aggregation-limit.patch netfilter-conntrack-re-fetch-conntrack-after-insertion.patch netfilter-nf_tables-sanitize-nft_set_desc_concat_parse.patch raid5-introduce-md_broken.patch x86-kvm-alloc-dummy-async-pf-token-outside-of-raw-spinlock.patch x86-kvm-use-correct-gfp-flags-for-preemption-disabled.patch xfs-detect-overflows-in-bmbt-records.patch xfs-fix-an-abba-deadlock-in-xfs_rename.patch xfs-fix-cil-throttle-hang-when-cil-space-used-going-backwards.patch xfs-fix-the-forward-progress-assertion-in-xfs_iwalk_run_callbacks.patch xfs-show-the-proper-user-quota-options.patch zsmalloc-fix-races-between-asynchronous-zspage-free-and-page-migration.patch --- diff --git a/queue-5.10/arm-dts-s5pv210-correct-interrupt-name-for-bluetooth-in-aries.patch b/queue-5.10/arm-dts-s5pv210-correct-interrupt-name-for-bluetooth-in-aries.patch new file mode 100644 index 00000000000..7876d43a363 --- /dev/null +++ b/queue-5.10/arm-dts-s5pv210-correct-interrupt-name-for-bluetooth-in-aries.patch @@ -0,0 +1,33 @@ +From 3f5e3d3a8b895c8a11da8b0063ba2022dd9e2045 Mon Sep 17 00:00:00 2001 +From: Jonathan Bakker +Date: Sun, 27 Mar 2022 11:08:51 -0700 +Subject: ARM: dts: s5pv210: Correct interrupt name for bluetooth in Aries + +From: Jonathan Bakker + +commit 3f5e3d3a8b895c8a11da8b0063ba2022dd9e2045 upstream. + +Correct the name of the bluetooth interrupt from host-wake to +host-wakeup. + +Fixes: 1c65b6184441b ("ARM: dts: s5pv210: Correct BCM4329 bluetooth node") +Cc: +Signed-off-by: Jonathan Bakker +Link: https://lore.kernel.org/r/CY4PR04MB0567495CFCBDC8D408D44199CB1C9@CY4PR04MB0567.namprd04.prod.outlook.com +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/s5pv210-aries.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/s5pv210-aries.dtsi ++++ b/arch/arm/boot/dts/s5pv210-aries.dtsi +@@ -896,7 +896,7 @@ + device-wakeup-gpios = <&gpg3 4 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gph2>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; +- interrupt-names = "host-wake"; ++ interrupt-names = "host-wakeup"; + }; + }; + diff --git a/queue-5.10/bluetooth-hci_qca-use-del_timer_sync-before-freeing.patch b/queue-5.10/bluetooth-hci_qca-use-del_timer_sync-before-freeing.patch new file mode 100644 index 00000000000..b3f8f9d7679 --- /dev/null +++ b/queue-5.10/bluetooth-hci_qca-use-del_timer_sync-before-freeing.patch @@ -0,0 +1,44 @@ +From 72ef98445aca568a81c2da050532500a8345ad3a Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +Date: Tue, 5 Apr 2022 10:02:00 -0400 +Subject: Bluetooth: hci_qca: Use del_timer_sync() before freeing + +From: Steven Rostedt + +commit 72ef98445aca568a81c2da050532500a8345ad3a upstream. + +While looking at a crash report on a timer list being corrupted, which +usually happens when a timer is freed while still active. This is +commonly triggered by code calling del_timer() instead of +del_timer_sync() just before freeing. + +One possible culprit is the hci_qca driver, which does exactly that. + +Eric mentioned that wake_retrans_timer could be rearmed via the work +queue, so also move the destruction of the work queue before +del_timer_sync(). + +Cc: Eric Dumazet +Cc: stable@vger.kernel.org +Fixes: 0ff252c1976da ("Bluetooth: hciuart: Add support QCA chipset for UART") +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bluetooth/hci_qca.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/bluetooth/hci_qca.c ++++ b/drivers/bluetooth/hci_qca.c +@@ -689,9 +689,9 @@ static int qca_close(struct hci_uart *hu + skb_queue_purge(&qca->tx_wait_q); + skb_queue_purge(&qca->txq); + skb_queue_purge(&qca->rx_memdump_q); +- del_timer(&qca->tx_idle_timer); +- del_timer(&qca->wake_retrans_timer); + destroy_workqueue(qca->workqueue); ++ del_timer_sync(&qca->tx_idle_timer); ++ del_timer_sync(&qca->wake_retrans_timer); + qca->hu = NULL; + + kfree_skb(qca->rx_skb); diff --git a/queue-5.10/crypto-caam-fix-i.mx6sx-entropy-delay-value.patch b/queue-5.10/crypto-caam-fix-i.mx6sx-entropy-delay-value.patch new file mode 100644 index 00000000000..b98b61e871e --- /dev/null +++ b/queue-5.10/crypto-caam-fix-i.mx6sx-entropy-delay-value.patch @@ -0,0 +1,85 @@ +From 4ee4cdad368a26de3967f2975806a9ee2fa245df Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Wed, 20 Apr 2022 09:06:01 -0300 +Subject: crypto: caam - fix i.MX6SX entropy delay value +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Fabio Estevam + +commit 4ee4cdad368a26de3967f2975806a9ee2fa245df upstream. + +Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance +in HRWNG") the following CAAM errors can be seen on i.MX6SX: + +caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error +hwrng: no data available + +This error is due to an incorrect entropy delay for i.MX6SX. + +Fix it by increasing the minimum entropy delay for i.MX6SX +as done in U-Boot: +https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-gaurav.jain@nxp.com/ + +As explained in the U-Boot patch: + +"RNG self tests are run to determine the correct entropy delay. +Such tests are executed with different voltages and temperatures to identify +the worst case value for the entropy delay. For i.MX6SX, it was determined +that after adding a margin value of 1000 the minimum entropy delay should be +at least 12000." + +Cc: +Fixes: 358ba762d9f1 ("crypto: caam - enable prediction resistance in HRWNG") +Signed-off-by: Fabio Estevam +Reviewed-by: Horia Geantă +Reviewed-by: Vabhav Sharma +Reviewed-by: Gaurav Jain +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/caam/ctrl.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/drivers/crypto/caam/ctrl.c ++++ b/drivers/crypto/caam/ctrl.c +@@ -609,6 +609,13 @@ static bool check_version(struct fsl_mc_ + } + #endif + ++static bool needs_entropy_delay_adjustment(void) ++{ ++ if (of_machine_is_compatible("fsl,imx6sx")) ++ return true; ++ return false; ++} ++ + /* Probe routine for CAAM top (controller) level */ + static int caam_probe(struct platform_device *pdev) + { +@@ -855,6 +862,8 @@ static int caam_probe(struct platform_de + * Also, if a handle was instantiated, do not change + * the TRNG parameters. + */ ++ if (needs_entropy_delay_adjustment()) ++ ent_delay = 12000; + if (!(ctrlpriv->rng4_sh_init || inst_handles)) { + dev_info(dev, + "Entropy delay = %u\n", +@@ -871,6 +880,15 @@ static int caam_probe(struct platform_de + */ + ret = instantiate_rng(dev, inst_handles, + gen_sk); ++ /* ++ * Entropy delay is determined via TRNG characterization. ++ * TRNG characterization is run across different voltages ++ * and temperatures. ++ * If worst case value for ent_dly is identified, ++ * the loop can be skipped for that platform. ++ */ ++ if (needs_entropy_delay_adjustment()) ++ break; + if (ret == -EAGAIN) + /* + * if here, the loop will rerun, diff --git a/queue-5.10/crypto-drbg-make-reseeding-from-get_random_bytes-synchronous.patch b/queue-5.10/crypto-drbg-make-reseeding-from-get_random_bytes-synchronous.patch new file mode 100644 index 00000000000..0fea76181ea --- /dev/null +++ b/queue-5.10/crypto-drbg-make-reseeding-from-get_random_bytes-synchronous.patch @@ -0,0 +1,231 @@ +From foo@baz Fri Jun 3 04:46:19 PM CEST 2022 +From: "Jason A. Donenfeld" +Date: Thu, 2 Jun 2022 22:22:32 +0200 +Subject: crypto: drbg - make reseeding from get_random_bytes() synchronous +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Message-ID: <20220602202232.281326-6-Jason@zx2c4.com> + +From: Nicolai Stange + +commit 074bcd4000e0d812bc253f86fedc40f81ed59ccc upstream. + +get_random_bytes() usually hasn't full entropy available by the time DRBG +instances are first getting seeded from it during boot. Thus, the DRBG +implementation registers random_ready_callbacks which would in turn +schedule some work for reseeding the DRBGs once get_random_bytes() has +sufficient entropy available. + +For reference, the relevant history around handling DRBG (re)seeding in +the context of a not yet fully seeded get_random_bytes() is: + + commit 16b369a91d0d ("random: Blocking API for accessing + nonblocking_pool") + commit 4c7879907edd ("crypto: drbg - add async seeding operation") + + commit 205a525c3342 ("random: Add callback API for random pool + readiness") + commit 57225e679788 ("crypto: drbg - Use callback API for random + readiness") + commit c2719503f5e1 ("random: Remove kernel blocking API") + +However, some time later, the initialization state of get_random_bytes() +has been made queryable via rng_is_initialized() introduced with commit +9a47249d444d ("random: Make crng state queryable"). This primitive now +allows for streamlining the DRBG reseeding from get_random_bytes() by +replacing that aforementioned asynchronous work scheduling from +random_ready_callbacks with some simpler, synchronous code in +drbg_generate() next to the related logic already present therein. Apart +from improving overall code readability, this change will also enable DRBG +users to rely on wait_for_random_bytes() for ensuring that the initial +seeding has completed, if desired. + +The previous patches already laid the grounds by making drbg_seed() to +record at each DRBG instance whether it was being seeded at a time when +rng_is_initialized() still had been false as indicated by +->seeded == DRBG_SEED_STATE_PARTIAL. + +All that remains to be done now is to make drbg_generate() check for this +condition, determine whether rng_is_initialized() has flipped to true in +the meanwhile and invoke a reseed from get_random_bytes() if so. + +Make this move: +- rename the former drbg_async_seed() work handler, i.e. the one in charge + of reseeding a DRBG instance from get_random_bytes(), to + "drbg_seed_from_random()", +- change its signature as appropriate, i.e. make it take a struct + drbg_state rather than a work_struct and change its return type from + "void" to "int" in order to allow for passing error information from + e.g. its __drbg_seed() invocation onwards to callers, +- make drbg_generate() invoke this drbg_seed_from_random() once it + encounters a DRBG instance with ->seeded == DRBG_SEED_STATE_PARTIAL by + the time rng_is_initialized() has flipped to true and +- prune everything related to the former, random_ready_callback based + mechanism. + +As drbg_seed_from_random() is now getting invoked from drbg_generate() with +the ->drbg_mutex being held, it must not attempt to recursively grab it +once again. Remove the corresponding mutex operations from what is now +drbg_seed_from_random(). Furthermore, as drbg_seed_from_random() can now +report errors directly to its caller, there's no need for it to temporarily +switch the DRBG's ->seeded state to DRBG_SEED_STATE_UNSEEDED so that a +failure of the subsequently invoked __drbg_seed() will get signaled to +drbg_generate(). Don't do it then. + +Signed-off-by: Nicolai Stange +Signed-off-by: Herbert Xu +[Jason: for stable, undid the modifications for the backport of 5acd3548.] +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + crypto/drbg.c | 61 +++++++++----------------------------------------- + drivers/char/random.c | 2 - + include/crypto/drbg.h | 2 - + 3 files changed, 11 insertions(+), 54 deletions(-) + +--- a/crypto/drbg.c ++++ b/crypto/drbg.c +@@ -1086,12 +1086,10 @@ static inline int drbg_get_random_bytes( + return 0; + } + +-static void drbg_async_seed(struct work_struct *work) ++static int drbg_seed_from_random(struct drbg_state *drbg) + { + struct drbg_string data; + LIST_HEAD(seedlist); +- struct drbg_state *drbg = container_of(work, struct drbg_state, +- seed_work); + unsigned int entropylen = drbg_sec_strength(drbg->core->flags); + unsigned char entropy[32]; + int ret; +@@ -1102,23 +1100,15 @@ static void drbg_async_seed(struct work_ + drbg_string_fill(&data, entropy, entropylen); + list_add_tail(&data.list, &seedlist); + +- mutex_lock(&drbg->drbg_mutex); +- + ret = drbg_get_random_bytes(drbg, entropy, entropylen); + if (ret) +- goto unlock; +- +- /* Reset ->seeded so that if __drbg_seed fails the next +- * generate call will trigger a reseed. +- */ +- drbg->seeded = DRBG_SEED_STATE_UNSEEDED; ++ goto out; + +- __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); +- +-unlock: +- mutex_unlock(&drbg->drbg_mutex); ++ ret = __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); + ++out: + memzero_explicit(entropy, entropylen); ++ return ret; + } + + /* +@@ -1421,6 +1411,11 @@ static int drbg_generate(struct drbg_sta + goto err; + /* 9.3.1 step 7.4 */ + addtl = NULL; ++ } else if (rng_is_initialized() && ++ drbg->seeded == DRBG_SEED_STATE_PARTIAL) { ++ len = drbg_seed_from_random(drbg); ++ if (len) ++ goto err; + } + + if (addtl && 0 < addtl->len) +@@ -1513,44 +1508,15 @@ static int drbg_generate_long(struct drb + return 0; + } + +-static int drbg_schedule_async_seed(struct notifier_block *nb, unsigned long action, void *data) +-{ +- struct drbg_state *drbg = container_of(nb, struct drbg_state, +- random_ready); +- +- schedule_work(&drbg->seed_work); +- return 0; +-} +- + static int drbg_prepare_hrng(struct drbg_state *drbg) + { +- int err; +- + /* We do not need an HRNG in test mode. */ + if (list_empty(&drbg->test_data.list)) + return 0; + + drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0); + +- INIT_WORK(&drbg->seed_work, drbg_async_seed); +- +- drbg->random_ready.notifier_call = drbg_schedule_async_seed; +- err = register_random_ready_notifier(&drbg->random_ready); +- +- switch (err) { +- case 0: +- break; +- +- case -EALREADY: +- err = 0; +- fallthrough; +- +- default: +- drbg->random_ready.notifier_call = NULL; +- return err; +- } +- +- return err; ++ return 0; + } + + /* +@@ -1644,11 +1610,6 @@ free_everything: + */ + static int drbg_uninstantiate(struct drbg_state *drbg) + { +- if (drbg->random_ready.notifier_call) { +- unregister_random_ready_notifier(&drbg->random_ready); +- cancel_work_sync(&drbg->seed_work); +- } +- + if (!IS_ERR_OR_NULL(drbg->jent)) + crypto_free_rng(drbg->jent); + drbg->jent = NULL; +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -163,7 +163,6 @@ int __cold register_random_ready_notifie + spin_unlock_irqrestore(&random_ready_chain_lock, flags); + return ret; + } +-EXPORT_SYMBOL(register_random_ready_notifier); + + /* + * Delete a previously registered readiness callback function. +@@ -178,7 +177,6 @@ int __cold unregister_random_ready_notif + spin_unlock_irqrestore(&random_ready_chain_lock, flags); + return ret; + } +-EXPORT_SYMBOL(unregister_random_ready_notifier); + + static void __cold process_random_ready_list(void) + { +--- a/include/crypto/drbg.h ++++ b/include/crypto/drbg.h +@@ -137,12 +137,10 @@ struct drbg_state { + bool pr; /* Prediction resistance enabled? */ + bool fips_primed; /* Continuous test primed? */ + unsigned char *prev; /* FIPS 140-2 continuous test value */ +- struct work_struct seed_work; /* asynchronous seeding support */ + struct crypto_rng *jent; + const struct drbg_state_ops *d_ops; + const struct drbg_core *core; + struct drbg_string test_data; +- struct notifier_block random_ready; + }; + + static inline __u8 drbg_statelen(struct drbg_state *drbg) diff --git a/queue-5.10/crypto-drbg-move-dynamic-reseed_threshold-adjustments-to-__drbg_seed.patch b/queue-5.10/crypto-drbg-move-dynamic-reseed_threshold-adjustments-to-__drbg_seed.patch new file mode 100644 index 00000000000..e26c87cea5a --- /dev/null +++ b/queue-5.10/crypto-drbg-move-dynamic-reseed_threshold-adjustments-to-__drbg_seed.patch @@ -0,0 +1,109 @@ +From foo@baz Fri Jun 3 04:46:19 PM CEST 2022 +From: "Jason A. Donenfeld" +Date: Thu, 2 Jun 2022 22:22:31 +0200 +Subject: crypto: drbg - move dynamic ->reseed_threshold adjustments to __drbg_seed() +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Message-ID: <20220602202232.281326-5-Jason@zx2c4.com> + +From: Nicolai Stange + +commit 262d83a4290c331cd4f617a457408bdb82fbb738 upstream. + +Since commit 42ea507fae1a ("crypto: drbg - reseed often if seedsource is +degraded"), the maximum seed lifetime represented by ->reseed_threshold +gets temporarily lowered if the get_random_bytes() source cannot provide +sufficient entropy yet, as is common during boot, and restored back to +the original value again once that has changed. + +More specifically, if the add_random_ready_callback() invoked from +drbg_prepare_hrng() in the course of DRBG instantiation does not return +-EALREADY, that is, if get_random_bytes() has not been fully initialized +at this point yet, drbg_prepare_hrng() will lower ->reseed_threshold +to a value of 50. The drbg_async_seed() scheduled from said +random_ready_callback will eventually restore the original value. + +A future patch will replace the random_ready_callback based notification +mechanism and thus, there will be no add_random_ready_callback() return +value anymore which could get compared to -EALREADY. + +However, there's __drbg_seed() which gets invoked in the course of both, +the DRBG instantiation as well as the eventual reseeding from +get_random_bytes() in aforementioned drbg_async_seed(), if any. Moreover, +it knows about the get_random_bytes() initialization state by the time the +seed data had been obtained from it: the new_seed_state argument introduced +with the previous patch would get set to DRBG_SEED_STATE_PARTIAL in case +get_random_bytes() had not been fully initialized yet and to +DRBG_SEED_STATE_FULL otherwise. Thus, __drbg_seed() provides a convenient +alternative for managing that ->reseed_threshold lowering and restoring at +a central place. + +Move all ->reseed_threshold adjustment code from drbg_prepare_hrng() and +drbg_async_seed() respectively to __drbg_seed(). Make __drbg_seed() +lower the ->reseed_threshold to 50 in case its new_seed_state argument +equals DRBG_SEED_STATE_PARTIAL and let it restore the original value +otherwise. + +There is no change in behaviour. + +Signed-off-by: Nicolai Stange +Reviewed-by: Stephan Müller +Signed-off-by: Herbert Xu +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + crypto/drbg.c | 30 +++++++++++++++++++++--------- + 1 file changed, 21 insertions(+), 9 deletions(-) + +--- a/crypto/drbg.c ++++ b/crypto/drbg.c +@@ -1046,6 +1046,27 @@ static inline int __drbg_seed(struct drb + /* 10.1.1.2 / 10.1.1.3 step 5 */ + drbg->reseed_ctr = 1; + ++ switch (drbg->seeded) { ++ case DRBG_SEED_STATE_UNSEEDED: ++ /* Impossible, but handle it to silence compiler warnings. */ ++ fallthrough; ++ case DRBG_SEED_STATE_PARTIAL: ++ /* ++ * Require frequent reseeds until the seed source is ++ * fully initialized. ++ */ ++ drbg->reseed_threshold = 50; ++ break; ++ ++ case DRBG_SEED_STATE_FULL: ++ /* ++ * Seed source has become fully initialized, frequent ++ * reseeds no longer required. ++ */ ++ drbg->reseed_threshold = drbg_max_requests(drbg); ++ break; ++ } ++ + return ret; + } + +@@ -1094,9 +1115,6 @@ static void drbg_async_seed(struct work_ + + __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); + +- if (drbg->seeded == DRBG_SEED_STATE_FULL) +- drbg->reseed_threshold = drbg_max_requests(drbg); +- + unlock: + mutex_unlock(&drbg->drbg_mutex); + +@@ -1532,12 +1550,6 @@ static int drbg_prepare_hrng(struct drbg + return err; + } + +- /* +- * Require frequent reseeds until the seed source is fully +- * initialized. +- */ +- drbg->reseed_threshold = 50; +- + return err; + } + diff --git a/queue-5.10/crypto-drbg-prepare-for-more-fine-grained-tracking-of-seeding-state.patch b/queue-5.10/crypto-drbg-prepare-for-more-fine-grained-tracking-of-seeding-state.patch new file mode 100644 index 00000000000..8745a186fc7 --- /dev/null +++ b/queue-5.10/crypto-drbg-prepare-for-more-fine-grained-tracking-of-seeding-state.patch @@ -0,0 +1,138 @@ +From foo@baz Fri Jun 3 04:46:19 PM CEST 2022 +From: "Jason A. Donenfeld" +Date: Thu, 2 Jun 2022 22:22:29 +0200 +Subject: crypto: drbg - prepare for more fine-grained tracking of seeding state +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Message-ID: <20220602202232.281326-3-Jason@zx2c4.com> + +From: Nicolai Stange + +commit ce8ce31b2c5c8b18667784b8c515650c65d57b4e upstream. + +There are two different randomness sources the DRBGs are getting seeded +from, namely the jitterentropy source (if enabled) and get_random_bytes(). +At initial DRBG seeding time during boot, the latter might not have +collected sufficient entropy for seeding itself yet and thus, the DRBG +implementation schedules a reseed work from a random_ready_callback once +that has happened. This is particularly important for the !->pr DRBG +instances, for which (almost) no further reseeds are getting triggered +during their lifetime. + +Because collecting data from the jitterentropy source is a rather expensive +operation, the aforementioned asynchronously scheduled reseed work +restricts itself to get_random_bytes() only. That is, it in some sense +amends the initial DRBG seed derived from jitterentropy output at full +(estimated) entropy with fresh randomness obtained from get_random_bytes() +once that has been seeded with sufficient entropy itself. + +With the advent of rng_is_initialized(), there is no real need for doing +the reseed operation from an asynchronously scheduled work anymore and a +subsequent patch will make it synchronous by moving it next to related +logic already present in drbg_generate(). + +However, for tracking whether a full reseed including the jitterentropy +source is required or a "partial" reseed involving only get_random_bytes() +would be sufficient already, the boolean struct drbg_state's ->seeded +member must become a tristate value. + +Prepare for this by introducing the new enum drbg_seed_state and change +struct drbg_state's ->seeded member's type from bool to that type. + +For facilitating review, enum drbg_seed_state is made to only contain +two members corresponding to the former ->seeded values of false and true +resp. at this point: DRBG_SEED_STATE_UNSEEDED and DRBG_SEED_STATE_FULL. A +third one for tracking the intermediate state of "seeded from jitterentropy +only" will be introduced with a subsequent patch. + +There is no change in behaviour at this point. + +Signed-off-by: Nicolai Stange +Reviewed-by: Stephan Müller +Signed-off-by: Herbert Xu +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + crypto/drbg.c | 19 ++++++++++--------- + include/crypto/drbg.h | 7 ++++++- + 2 files changed, 16 insertions(+), 10 deletions(-) + +--- a/crypto/drbg.c ++++ b/crypto/drbg.c +@@ -1042,7 +1042,7 @@ static inline int __drbg_seed(struct drb + if (ret) + return ret; + +- drbg->seeded = true; ++ drbg->seeded = DRBG_SEED_STATE_FULL; + /* 10.1.1.2 / 10.1.1.3 step 5 */ + drbg->reseed_ctr = 1; + +@@ -1087,14 +1087,14 @@ static void drbg_async_seed(struct work_ + if (ret) + goto unlock; + +- /* Set seeded to false so that if __drbg_seed fails the +- * next generate call will trigger a reseed. ++ /* Reset ->seeded so that if __drbg_seed fails the next ++ * generate call will trigger a reseed. + */ +- drbg->seeded = false; ++ drbg->seeded = DRBG_SEED_STATE_UNSEEDED; + + __drbg_seed(drbg, &seedlist, true); + +- if (drbg->seeded) ++ if (drbg->seeded == DRBG_SEED_STATE_FULL) + drbg->reseed_threshold = drbg_max_requests(drbg); + + unlock: +@@ -1385,13 +1385,14 @@ static int drbg_generate(struct drbg_sta + * here. The spec is a bit convoluted here, we make it simpler. + */ + if (drbg->reseed_threshold < drbg->reseed_ctr) +- drbg->seeded = false; ++ drbg->seeded = DRBG_SEED_STATE_UNSEEDED; + +- if (drbg->pr || !drbg->seeded) { ++ if (drbg->pr || drbg->seeded == DRBG_SEED_STATE_UNSEEDED) { + pr_devel("DRBG: reseeding before generation (prediction " + "resistance: %s, state %s)\n", + drbg->pr ? "true" : "false", +- drbg->seeded ? "seeded" : "unseeded"); ++ (drbg->seeded == DRBG_SEED_STATE_FULL ? ++ "seeded" : "unseeded")); + /* 9.3.1 steps 7.1 through 7.3 */ + len = drbg_seed(drbg, addtl, true); + if (len) +@@ -1576,7 +1577,7 @@ static int drbg_instantiate(struct drbg_ + if (!drbg->core) { + drbg->core = &drbg_cores[coreref]; + drbg->pr = pr; +- drbg->seeded = false; ++ drbg->seeded = DRBG_SEED_STATE_UNSEEDED; + drbg->reseed_threshold = drbg_max_requests(drbg); + + ret = drbg_alloc_state(drbg); +--- a/include/crypto/drbg.h ++++ b/include/crypto/drbg.h +@@ -105,6 +105,11 @@ struct drbg_test_data { + struct drbg_string *testentropy; /* TEST PARAMETER: test entropy */ + }; + ++enum drbg_seed_state { ++ DRBG_SEED_STATE_UNSEEDED, ++ DRBG_SEED_STATE_FULL, ++}; ++ + struct drbg_state { + struct mutex drbg_mutex; /* lock around DRBG */ + unsigned char *V; /* internal state 10.1.1.1 1a) */ +@@ -127,7 +132,7 @@ struct drbg_state { + struct crypto_wait ctr_wait; /* CTR mode async wait obj */ + struct scatterlist sg_in, sg_out; /* CTR mode SGLs */ + +- bool seeded; /* DRBG fully seeded? */ ++ enum drbg_seed_state seeded; /* DRBG fully seeded? */ + bool pr; /* Prediction resistance enabled? */ + bool fips_primed; /* Continuous test primed? */ + unsigned char *prev; /* FIPS 140-2 continuous test value */ diff --git a/queue-5.10/crypto-drbg-track-whether-drbg-was-seeded-with-rng_is_initialized.patch b/queue-5.10/crypto-drbg-track-whether-drbg-was-seeded-with-rng_is_initialized.patch new file mode 100644 index 00000000000..32bbf0acb5d --- /dev/null +++ b/queue-5.10/crypto-drbg-track-whether-drbg-was-seeded-with-rng_is_initialized.patch @@ -0,0 +1,133 @@ +From foo@baz Fri Jun 3 04:46:19 PM CEST 2022 +From: "Jason A. Donenfeld" +Date: Thu, 2 Jun 2022 22:22:30 +0200 +Subject: crypto: drbg - track whether DRBG was seeded with !rng_is_initialized() +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Message-ID: <20220602202232.281326-4-Jason@zx2c4.com> + +From: Nicolai Stange + +commit 2bcd25443868aa8863779a6ebc6c9319633025d2 upstream. + +Currently, the DRBG implementation schedules asynchronous works from +random_ready_callbacks for reseeding the DRBG instances with output from +get_random_bytes() once the latter has sufficient entropy available. + +However, as the get_random_bytes() initialization state can get queried by +means of rng_is_initialized() now, there is no real need for this +asynchronous reseeding logic anymore and it's better to keep things simple +by doing it synchronously when needed instead, i.e. from drbg_generate() +once rng_is_initialized() has flipped to true. + +Of course, for this to work, drbg_generate() would need some means by which +it can tell whether or not rng_is_initialized() has flipped to true since +the last seeding from get_random_bytes(). Or equivalently, whether or not +the last seed from get_random_bytes() has happened when +rng_is_initialized() was still evaluating to false. + +As it currently stands, enum drbg_seed_state allows for the representation +of two different DRBG seeding states: DRBG_SEED_STATE_UNSEEDED and +DRBG_SEED_STATE_FULL. The former makes drbg_generate() to invoke a full +reseeding operation involving both, the rather expensive jitterentropy as +well as the get_random_bytes() randomness sources. The DRBG_SEED_STATE_FULL +state on the other hand implies that no reseeding at all is required for a +!->pr DRBG variant. + +Introduce the new DRBG_SEED_STATE_PARTIAL state to enum drbg_seed_state for +representing the condition that a DRBG was being seeded when +rng_is_initialized() had still been false. In particular, this new state +implies that +- the given DRBG instance has been fully seeded from the jitterentropy + source (if enabled) +- and drbg_generate() is supposed to reseed from get_random_bytes() + *only* once rng_is_initialized() turns to true. + +Up to now, the __drbg_seed() helper used to set the given DRBG instance's +->seeded state to constant DRBG_SEED_STATE_FULL. Introduce a new argument +allowing for the specification of the to be written ->seeded value instead. +Make the first of its two callers, drbg_seed(), determine the appropriate +value based on rng_is_initialized(). The remaining caller, +drbg_async_seed(), is known to get invoked only once rng_is_initialized() +is true, hence let it pass constant DRBG_SEED_STATE_FULL for the new +argument to __drbg_seed(). + +There is no change in behaviour, except for that the pr_devel() in +drbg_generate() would now report "unseeded" for ->pr DRBG instances which +had last been seeded when rng_is_initialized() was still evaluating to +false. + +Signed-off-by: Nicolai Stange +Reviewed-by: Stephan Müller +Signed-off-by: Herbert Xu +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + crypto/drbg.c | 12 ++++++++---- + include/crypto/drbg.h | 1 + + 2 files changed, 9 insertions(+), 4 deletions(-) + +--- a/crypto/drbg.c ++++ b/crypto/drbg.c +@@ -1035,14 +1035,14 @@ static const struct drbg_state_ops drbg_ + ******************************************************************/ + + static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed, +- int reseed) ++ int reseed, enum drbg_seed_state new_seed_state) + { + int ret = drbg->d_ops->update(drbg, seed, reseed); + + if (ret) + return ret; + +- drbg->seeded = DRBG_SEED_STATE_FULL; ++ drbg->seeded = new_seed_state; + /* 10.1.1.2 / 10.1.1.3 step 5 */ + drbg->reseed_ctr = 1; + +@@ -1092,7 +1092,7 @@ static void drbg_async_seed(struct work_ + */ + drbg->seeded = DRBG_SEED_STATE_UNSEEDED; + +- __drbg_seed(drbg, &seedlist, true); ++ __drbg_seed(drbg, &seedlist, true, DRBG_SEED_STATE_FULL); + + if (drbg->seeded == DRBG_SEED_STATE_FULL) + drbg->reseed_threshold = drbg_max_requests(drbg); +@@ -1122,6 +1122,7 @@ static int drbg_seed(struct drbg_state * + unsigned int entropylen = drbg_sec_strength(drbg->core->flags); + struct drbg_string data1; + LIST_HEAD(seedlist); ++ enum drbg_seed_state new_seed_state = DRBG_SEED_STATE_FULL; + + /* 9.1 / 9.2 / 9.3.1 step 3 */ + if (pers && pers->len > (drbg_max_addtl(drbg))) { +@@ -1149,6 +1150,9 @@ static int drbg_seed(struct drbg_state * + BUG_ON((entropylen * 2) > sizeof(entropy)); + + /* Get seed from in-kernel /dev/urandom */ ++ if (!rng_is_initialized()) ++ new_seed_state = DRBG_SEED_STATE_PARTIAL; ++ + ret = drbg_get_random_bytes(drbg, entropy, entropylen); + if (ret) + goto out; +@@ -1205,7 +1209,7 @@ static int drbg_seed(struct drbg_state * + memset(drbg->C, 0, drbg_statelen(drbg)); + } + +- ret = __drbg_seed(drbg, &seedlist, reseed); ++ ret = __drbg_seed(drbg, &seedlist, reseed, new_seed_state); + + out: + memzero_explicit(entropy, entropylen * 2); +--- a/include/crypto/drbg.h ++++ b/include/crypto/drbg.h +@@ -107,6 +107,7 @@ struct drbg_test_data { + + enum drbg_seed_state { + DRBG_SEED_STATE_UNSEEDED, ++ DRBG_SEED_STATE_PARTIAL, /* Seeded with !rng_is_initialized() */ + DRBG_SEED_STATE_FULL, + }; + diff --git a/queue-5.10/crypto-ecrdsa-fix-incorrect-use-of-vli_cmp.patch b/queue-5.10/crypto-ecrdsa-fix-incorrect-use-of-vli_cmp.patch new file mode 100644 index 00000000000..8b8ec0af6c6 --- /dev/null +++ b/queue-5.10/crypto-ecrdsa-fix-incorrect-use-of-vli_cmp.patch @@ -0,0 +1,51 @@ +From 7cc7ab73f83ee6d50dc9536bc3355495d8600fad Mon Sep 17 00:00:00 2001 +From: Vitaly Chikunov +Date: Thu, 21 Apr 2022 20:25:10 +0300 +Subject: crypto: ecrdsa - Fix incorrect use of vli_cmp + +From: Vitaly Chikunov + +commit 7cc7ab73f83ee6d50dc9536bc3355495d8600fad upstream. + +Correctly compare values that shall be greater-or-equal and not just +greater. + +Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") +Cc: +Signed-off-by: Vitaly Chikunov +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/ecrdsa.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/crypto/ecrdsa.c ++++ b/crypto/ecrdsa.c +@@ -113,15 +113,15 @@ static int ecrdsa_verify(struct akcipher + + /* Step 1: verify that 0 < r < q, 0 < s < q */ + if (vli_is_zero(r, ndigits) || +- vli_cmp(r, ctx->curve->n, ndigits) == 1 || ++ vli_cmp(r, ctx->curve->n, ndigits) >= 0 || + vli_is_zero(s, ndigits) || +- vli_cmp(s, ctx->curve->n, ndigits) == 1) ++ vli_cmp(s, ctx->curve->n, ndigits) >= 0) + return -EKEYREJECTED; + + /* Step 2: calculate hash (h) of the message (passed as input) */ + /* Step 3: calculate e = h \mod q */ + vli_from_le64(e, digest, ndigits); +- if (vli_cmp(e, ctx->curve->n, ndigits) == 1) ++ if (vli_cmp(e, ctx->curve->n, ndigits) >= 0) + vli_sub(e, e, ctx->curve->n, ndigits); + if (vli_is_zero(e, ndigits)) + e[0] = 1; +@@ -137,7 +137,7 @@ static int ecrdsa_verify(struct akcipher + /* Step 6: calculate point C = z_1P + z_2Q, and R = x_c \mod q */ + ecc_point_mult_shamir(&cc, z1, &ctx->curve->g, z2, &ctx->pub_key, + ctx->curve); +- if (vli_cmp(cc.x, ctx->curve->n, ndigits) == 1) ++ if (vli_cmp(cc.x, ctx->curve->n, ndigits) >= 0) + vli_sub(cc.x, cc.x, ctx->curve->n, ndigits); + + /* Step 7: if R == r signature is valid */ diff --git a/queue-5.10/dm-crypt-make-printing-of-the-key-constant-time.patch b/queue-5.10/dm-crypt-make-printing-of-the-key-constant-time.patch new file mode 100644 index 00000000000..6521d3867f0 --- /dev/null +++ b/queue-5.10/dm-crypt-make-printing-of-the-key-constant-time.patch @@ -0,0 +1,58 @@ +From 567dd8f34560fa221a6343729474536aa7ede4fd Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 25 Apr 2022 08:53:29 -0400 +Subject: dm crypt: make printing of the key constant-time + +From: Mikulas Patocka + +commit 567dd8f34560fa221a6343729474536aa7ede4fd upstream. + +The device mapper dm-crypt target is using scnprintf("%02x", cc->key[i]) to +report the current key to userspace. However, this is not a constant-time +operation and it may leak information about the key via timing, via cache +access patterns or via the branch predictor. + +Change dm-crypt's key printing to use "%c" instead of "%02x". Also +introduce hex2asc() that carefully avoids any branching or memory +accesses when converting a number in the range 0 ... 15 to an ascii +character. + +Cc: stable@vger.kernel.org +Signed-off-by: Mikulas Patocka +Tested-by: Milan Broz +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-crypt.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/md/dm-crypt.c ++++ b/drivers/md/dm-crypt.c +@@ -3404,6 +3404,11 @@ static int crypt_map(struct dm_target *t + return DM_MAPIO_SUBMITTED; + } + ++static char hex2asc(unsigned char c) ++{ ++ return c + '0' + ((unsigned)(9 - c) >> 4 & 0x27); ++} ++ + static void crypt_status(struct dm_target *ti, status_type_t type, + unsigned status_flags, char *result, unsigned maxlen) + { +@@ -3422,9 +3427,12 @@ static void crypt_status(struct dm_targe + if (cc->key_size > 0) { + if (cc->key_string) + DMEMIT(":%u:%s", cc->key_size, cc->key_string); +- else +- for (i = 0; i < cc->key_size; i++) +- DMEMIT("%02x", cc->key[i]); ++ else { ++ for (i = 0; i < cc->key_size; i++) { ++ DMEMIT("%c%c", hex2asc(cc->key[i] >> 4), ++ hex2asc(cc->key[i] & 0xf)); ++ } ++ } + } else + DMEMIT("-"); + diff --git a/queue-5.10/dm-integrity-fix-error-code-in-dm_integrity_ctr.patch b/queue-5.10/dm-integrity-fix-error-code-in-dm_integrity_ctr.patch new file mode 100644 index 00000000000..1c213398f4e --- /dev/null +++ b/queue-5.10/dm-integrity-fix-error-code-in-dm_integrity_ctr.patch @@ -0,0 +1,37 @@ +From d3f2a14b8906df913cb04a706367b012db94a6e8 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 25 Apr 2022 14:56:48 +0300 +Subject: dm integrity: fix error code in dm_integrity_ctr() + +From: Dan Carpenter + +commit d3f2a14b8906df913cb04a706367b012db94a6e8 upstream. + +The "r" variable shadows an earlier "r" that has function scope. It +means that we accidentally return success instead of an error code. +Smatch has a warning for this: + + drivers/md/dm-integrity.c:4503 dm_integrity_ctr() + warn: missing error code 'r' + +Fixes: 7eada909bfd7 ("dm: add integrity target") +Cc: stable@vger.kernel.org +Signed-off-by: Dan Carpenter +Reviewed-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-integrity.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/md/dm-integrity.c ++++ b/drivers/md/dm-integrity.c +@@ -4327,8 +4327,6 @@ try_smaller_buffer: + } + + if (should_write_sb) { +- int r; +- + init_journal(ic, 0, ic->journal_sections, 0); + r = dm_integrity_failed(ic); + if (unlikely(r)) { diff --git a/queue-5.10/dm-stats-add-cond_resched-when-looping-over-entries.patch b/queue-5.10/dm-stats-add-cond_resched-when-looping-over-entries.patch new file mode 100644 index 00000000000..20d23feaffc --- /dev/null +++ b/queue-5.10/dm-stats-add-cond_resched-when-looping-over-entries.patch @@ -0,0 +1,80 @@ +From bfe2b0146c4d0230b68f5c71a64380ff8d361f8b Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Sun, 24 Apr 2022 16:43:00 -0400 +Subject: dm stats: add cond_resched when looping over entries + +From: Mikulas Patocka + +commit bfe2b0146c4d0230b68f5c71a64380ff8d361f8b upstream. + +dm-stats can be used with a very large number of entries (it is only +limited by 1/4 of total system memory), so add rescheduling points to +the loops that iterate over the entries. + +Cc: stable@vger.kernel.org +Signed-off-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-stats.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/md/dm-stats.c ++++ b/drivers/md/dm-stats.c +@@ -224,6 +224,7 @@ void dm_stats_cleanup(struct dm_stats *s + atomic_read(&shared->in_flight[READ]), + atomic_read(&shared->in_flight[WRITE])); + } ++ cond_resched(); + } + dm_stat_free(&s->rcu_head); + } +@@ -313,6 +314,7 @@ static int dm_stats_create(struct dm_sta + for (ni = 0; ni < n_entries; ni++) { + atomic_set(&s->stat_shared[ni].in_flight[READ], 0); + atomic_set(&s->stat_shared[ni].in_flight[WRITE], 0); ++ cond_resched(); + } + + if (s->n_histogram_entries) { +@@ -325,6 +327,7 @@ static int dm_stats_create(struct dm_sta + for (ni = 0; ni < n_entries; ni++) { + s->stat_shared[ni].tmp.histogram = hi; + hi += s->n_histogram_entries + 1; ++ cond_resched(); + } + } + +@@ -345,6 +348,7 @@ static int dm_stats_create(struct dm_sta + for (ni = 0; ni < n_entries; ni++) { + p[ni].histogram = hi; + hi += s->n_histogram_entries + 1; ++ cond_resched(); + } + } + } +@@ -474,6 +478,7 @@ static int dm_stats_list(struct dm_stats + } + DMEMIT("\n"); + } ++ cond_resched(); + } + mutex_unlock(&stats->mutex); + +@@ -750,6 +755,7 @@ static void __dm_stat_clear(struct dm_st + local_irq_enable(); + } + } ++ cond_resched(); + } + } + +@@ -865,6 +871,8 @@ static int dm_stats_print(struct dm_stat + + if (unlikely(sz + 1 >= maxlen)) + goto buffer_overflow; ++ ++ cond_resched(); + } + + if (clear) diff --git a/queue-5.10/dm-verity-set-dm_target_immutable-feature-flag.patch b/queue-5.10/dm-verity-set-dm_target_immutable-feature-flag.patch new file mode 100644 index 00000000000..4a91b79c0fc --- /dev/null +++ b/queue-5.10/dm-verity-set-dm_target_immutable-feature-flag.patch @@ -0,0 +1,35 @@ +From 4caae58406f8ceb741603eee460d79bacca9b1b5 Mon Sep 17 00:00:00 2001 +From: Sarthak Kukreti +Date: Tue, 31 May 2022 15:56:40 -0400 +Subject: dm verity: set DM_TARGET_IMMUTABLE feature flag + +From: Sarthak Kukreti + +commit 4caae58406f8ceb741603eee460d79bacca9b1b5 upstream. + +The device-mapper framework provides a mechanism to mark targets as +immutable (and hence fail table reloads that try to change the target +type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's +feature flags to prevent switching the verity target with a different +target type. + +Fixes: a4ffc152198e ("dm: add verity target") +Cc: stable@vger.kernel.org +Signed-off-by: Sarthak Kukreti +Reviewed-by: Kees Cook +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-verity-target.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/md/dm-verity-target.c ++++ b/drivers/md/dm-verity-target.c +@@ -1242,6 +1242,7 @@ bad: + + static struct target_type verity_target = { + .name = "verity", ++ .features = DM_TARGET_IMMUTABLE, + .version = {1, 7, 0}, + .module = THIS_MODULE, + .ctr = verity_ctr, diff --git a/queue-5.10/drm-i915-fix-wstringop-overflow-warning-in-call-to-intel_read_wm_latency.patch b/queue-5.10/drm-i915-fix-wstringop-overflow-warning-in-call-to-intel_read_wm_latency.patch new file mode 100644 index 00000000000..9a48ec4d088 --- /dev/null +++ b/queue-5.10/drm-i915-fix-wstringop-overflow-warning-in-call-to-intel_read_wm_latency.patch @@ -0,0 +1,57 @@ +From 336feb502a715909a8136eb6a62a83d7268a353b Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Wed, 27 Apr 2022 17:47:14 -0500 +Subject: drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Gustavo A. R. Silva + +commit 336feb502a715909a8136eb6a62a83d7268a353b upstream. + +Fix the following -Wstringop-overflow warnings when building with GCC-11: + +drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] + 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type ‘u16 *’ {aka ‘short unsigned int *’} +drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function ‘intel_read_wm_latency’ + 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, + | ^~~~~~~~~~~~~~~~~~~~~ + +by removing the over-specified array size from the argument declarations. + +It seems that this code is actually safe because the size of the +array depends on the hardware generation, and the function checks +for that. + +Notice that wm can be an array of 5 elements: +drivers/gpu/drm/i915/intel_pm.c:3109: intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); + +or an array of 8 elements: +drivers/gpu/drm/i915/intel_pm.c:3131: intel_read_wm_latency(dev_priv, dev_priv->wm.skl_latency); + +and the compiler legitimately complains about that. + +This helps with the ongoing efforts to globally enable +-Wstringop-overflow. + +Link: https://github.com/KSPP/linux/issues/181 +Signed-off-by: Gustavo A. R. Silva +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/intel_pm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -2846,7 +2846,7 @@ static void ilk_compute_wm_level(const s + } + + static void intel_read_wm_latency(struct drm_i915_private *dev_priv, +- u16 wm[8]) ++ u16 wm[]) + { + struct intel_uncore *uncore = &dev_priv->uncore; + diff --git a/queue-5.10/exfat-check-if-cluster-num-is-valid.patch b/queue-5.10/exfat-check-if-cluster-num-is-valid.patch new file mode 100644 index 00000000000..4e8bf0228e5 --- /dev/null +++ b/queue-5.10/exfat-check-if-cluster-num-is-valid.patch @@ -0,0 +1,108 @@ +From 64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d Mon Sep 17 00:00:00 2001 +From: Tadeusz Struk +Date: Tue, 17 May 2022 08:13:08 +0900 +Subject: exfat: check if cluster num is valid + +From: Tadeusz Struk + +commit 64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d upstream. + +Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. +This was triggered by reproducer calling truncute with size 0, +which causes the following trace: + +BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 +Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 + +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 + print_address_description+0x81/0x3c0 mm/kasan/report.c:233 + __kasan_report mm/kasan/report.c:419 [inline] + kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 + __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 + exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 + exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 + __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 + exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 + exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 + notify_change+0xb76/0xe10 fs/attr.c:336 + do_truncate+0x1ea/0x2d0 fs/open.c:65 + +Move the is_valid_cluster() helper from fatent.c to a common +header to make it reusable in other *.c files. And add is_valid_cluster() +to validate if cluster number is within valid range in exfat_clear_bitmap() +and exfat_set_bitmap(). + +Link: https://syzkaller.appspot.com/bug?id=50381fc73821ecae743b8cf24b4c9a04776f767c +Reported-by: syzbot+a4087e40b9c13aad7892@syzkaller.appspotmail.com +Fixes: 1e49a94cf707 ("exfat: add bitmap operations") +Cc: stable@vger.kernel.org # v5.7+ +Signed-off-by: Tadeusz Struk +Reviewed-by: Sungjong Seo +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman +--- + fs/exfat/balloc.c | 8 ++++++-- + fs/exfat/exfat_fs.h | 8 ++++++++ + fs/exfat/fatent.c | 8 -------- + 3 files changed, 14 insertions(+), 10 deletions(-) + +--- a/fs/exfat/balloc.c ++++ b/fs/exfat/balloc.c +@@ -148,7 +148,9 @@ int exfat_set_bitmap(struct inode *inode + struct super_block *sb = inode->i_sb; + struct exfat_sb_info *sbi = EXFAT_SB(sb); + +- WARN_ON(clu < EXFAT_FIRST_CLUSTER); ++ if (!is_valid_cluster(sbi, clu)) ++ return -EINVAL; ++ + ent_idx = CLUSTER_TO_BITMAP_ENT(clu); + i = BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); + b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); +@@ -166,7 +168,9 @@ void exfat_clear_bitmap(struct inode *in + struct exfat_sb_info *sbi = EXFAT_SB(sb); + struct exfat_mount_options *opts = &sbi->options; + +- WARN_ON(clu < EXFAT_FIRST_CLUSTER); ++ if (!is_valid_cluster(sbi, clu)) ++ return; ++ + ent_idx = CLUSTER_TO_BITMAP_ENT(clu); + i = BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx); + b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx); +--- a/fs/exfat/exfat_fs.h ++++ b/fs/exfat/exfat_fs.h +@@ -380,6 +380,14 @@ static inline int exfat_sector_to_cluste + EXFAT_RESERVED_CLUSTERS; + } + ++static inline bool is_valid_cluster(struct exfat_sb_info *sbi, ++ unsigned int clus) ++{ ++ if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <= clus) ++ return false; ++ return true; ++} ++ + /* super.c */ + int exfat_set_volume_dirty(struct super_block *sb); + int exfat_clear_volume_dirty(struct super_block *sb); +--- a/fs/exfat/fatent.c ++++ b/fs/exfat/fatent.c +@@ -81,14 +81,6 @@ int exfat_ent_set(struct super_block *sb + return 0; + } + +-static inline bool is_valid_cluster(struct exfat_sb_info *sbi, +- unsigned int clus) +-{ +- if (clus < EXFAT_FIRST_CLUSTER || sbi->num_clusters <= clus) +- return false; +- return true; +-} +- + int exfat_ent_get(struct super_block *sb, unsigned int loc, + unsigned int *content) + { diff --git a/queue-5.10/exfat-fix-referencing-wrong-parent-directory-information-after-renaming.patch b/queue-5.10/exfat-fix-referencing-wrong-parent-directory-information-after-renaming.patch new file mode 100644 index 00000000000..172347950a2 --- /dev/null +++ b/queue-5.10/exfat-fix-referencing-wrong-parent-directory-information-after-renaming.patch @@ -0,0 +1,98 @@ +From d8dad2588addd1d861ce19e7df3b702330f0c7e3 Mon Sep 17 00:00:00 2001 +From: Yuezhang Mo +Date: Mon, 4 Apr 2022 11:58:06 +0900 +Subject: exfat: fix referencing wrong parent directory information after renaming + +From: Yuezhang Mo + +commit d8dad2588addd1d861ce19e7df3b702330f0c7e3 upstream. + +During renaming, the parent directory information maybe +updated. But the file/directory still references to the +old parent directory information. + +This bug will cause 2 problems. + +(1) The renamed file can not be written. + + [10768.175172] exFAT-fs (sda1): error, failed to bmap (inode : 7afd50e4 iblock : 0, err : -5) + [10768.184285] exFAT-fs (sda1): Filesystem has been set read-only + ash: write error: Input/output error + +(2) Some dentries of the renamed file/directory are not set + to deleted after removing the file/directory. + +exfat_update_parent_info() is a workaround for the wrong parent +directory information being used after renaming. Now that bug is +fixed, this is no longer needed, so remove it. + +Fixes: 5f2aa075070c ("exfat: add inode operations") +Cc: stable@vger.kernel.org # v5.7+ +Signed-off-by: Yuezhang Mo +Reviewed-by: Andy Wu +Reviewed-by: Aoyama Wataru +Reviewed-by: Daniel Palmer +Reviewed-by: Sungjong Seo +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman +--- + fs/exfat/namei.c | 27 +-------------------------- + 1 file changed, 1 insertion(+), 26 deletions(-) + +--- a/fs/exfat/namei.c ++++ b/fs/exfat/namei.c +@@ -1061,6 +1061,7 @@ static int exfat_rename_file(struct inod + + exfat_remove_entries(inode, p_dir, oldentry, 0, + num_old_entries); ++ ei->dir = *p_dir; + ei->entry = newentry; + } else { + if (exfat_get_entry_type(epold) == TYPE_FILE) { +@@ -1151,28 +1152,6 @@ static int exfat_move_file(struct inode + return 0; + } + +-static void exfat_update_parent_info(struct exfat_inode_info *ei, +- struct inode *parent_inode) +-{ +- struct exfat_sb_info *sbi = EXFAT_SB(parent_inode->i_sb); +- struct exfat_inode_info *parent_ei = EXFAT_I(parent_inode); +- loff_t parent_isize = i_size_read(parent_inode); +- +- /* +- * the problem that struct exfat_inode_info caches wrong parent info. +- * +- * because of flag-mismatch of ei->dir, +- * there is abnormal traversing cluster chain. +- */ +- if (unlikely(parent_ei->flags != ei->dir.flags || +- parent_isize != EXFAT_CLU_TO_B(ei->dir.size, sbi) || +- parent_ei->start_clu != ei->dir.dir)) { +- exfat_chain_set(&ei->dir, parent_ei->start_clu, +- EXFAT_B_TO_CLU_ROUND_UP(parent_isize, sbi), +- parent_ei->flags); +- } +-} +- + /* rename or move a old file into a new file */ + static int __exfat_rename(struct inode *old_parent_inode, + struct exfat_inode_info *ei, struct inode *new_parent_inode, +@@ -1203,8 +1182,6 @@ static int __exfat_rename(struct inode * + return -ENOENT; + } + +- exfat_update_parent_info(ei, old_parent_inode); +- + exfat_chain_dup(&olddir, &ei->dir); + dentry = ei->entry; + +@@ -1225,8 +1202,6 @@ static int __exfat_rename(struct inode * + goto out; + } + +- exfat_update_parent_info(new_ei, new_parent_inode); +- + p_dir = &(new_ei->dir); + new_entry = new_ei->entry; + ep = exfat_get_dentry(sb, p_dir, new_entry, &new_bh, NULL); diff --git a/queue-5.10/hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch b/queue-5.10/hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch new file mode 100644 index 00000000000..90c0de7edb2 --- /dev/null +++ b/queue-5.10/hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch @@ -0,0 +1,50 @@ +From 95cd2cdc88c755dcd0a58b951faeb77742c733a4 Mon Sep 17 00:00:00 2001 +From: Tao Jin +Date: Sun, 3 Apr 2022 12:57:44 -0400 +Subject: HID: multitouch: add quirks to enable Lenovo X12 trackpoint + +From: Tao Jin + +commit 95cd2cdc88c755dcd0a58b951faeb77742c733a4 upstream. + +This applies the similar quirks used by previous generation devices +such as X1 tablet for X12 tablet, so that the trackpoint and buttons +can work. + +This patch was applied and tested working on 5.17.1 . + +Cc: stable@vger.kernel.org # 5.8+ given that it relies on 40d5bb87377a +Signed-off-by: Tao Jin +Signed-off-by: Benjamin Tissoires +Link: https://lore.kernel.org/r/CO6PR03MB6241CB276FCDC7F4CEDC34F6E1E29@CO6PR03MB6241.namprd03.prod.outlook.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-ids.h | 1 + + drivers/hid/hid-multitouch.c | 6 ++++++ + 2 files changed, 7 insertions(+) + +--- a/drivers/hid/hid-ids.h ++++ b/drivers/hid/hid-ids.h +@@ -743,6 +743,7 @@ + #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085 + #define USB_DEVICE_ID_LENOVO_X1_TAB 0x60a3 + #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 ++#define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe + #define USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E 0x600e + #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D 0x608d + #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019 +--- a/drivers/hid/hid-multitouch.c ++++ b/drivers/hid/hid-multitouch.c +@@ -1990,6 +1990,12 @@ static const struct hid_device_id mt_dev + USB_VENDOR_ID_LENOVO, + USB_DEVICE_ID_LENOVO_X1_TAB3) }, + ++ /* Lenovo X12 TAB Gen 1 */ ++ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT, ++ HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, ++ USB_VENDOR_ID_LENOVO, ++ USB_DEVICE_ID_LENOVO_X12_TAB) }, ++ + /* MosArt panels */ + { .driver_data = MT_CLS_CONFIDENCE_MINUS_ONE, + MT_USB_DEVICE(USB_VENDOR_ID_ASUS, diff --git a/queue-5.10/hid-multitouch-add-support-for-google-whiskers-touchpad.patch b/queue-5.10/hid-multitouch-add-support-for-google-whiskers-touchpad.patch new file mode 100644 index 00000000000..228584c6138 --- /dev/null +++ b/queue-5.10/hid-multitouch-add-support-for-google-whiskers-touchpad.patch @@ -0,0 +1,33 @@ +From 1d07cef7fd7599450b3d03e1915efc2a96e1f03f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Ma=C5=9Blanka?= +Date: Tue, 5 Apr 2022 17:04:07 +0200 +Subject: HID: multitouch: Add support for Google Whiskers Touchpad + +From: Marek Maślanka + +commit 1d07cef7fd7599450b3d03e1915efc2a96e1f03f upstream. + +The Google Whiskers touchpad does not work properly with the default +multitouch configuration. Instead, use the same configuration as Google +Rose. + +Signed-off-by: Marek Maslanka +Acked-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-multitouch.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/hid/hid-multitouch.c ++++ b/drivers/hid/hid-multitouch.c +@@ -2129,6 +2129,9 @@ static const struct hid_device_id mt_dev + { .driver_data = MT_CLS_GOOGLE, + HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_GOOGLE, + USB_DEVICE_ID_GOOGLE_TOUCH_ROSE) }, ++ { .driver_data = MT_CLS_GOOGLE, ++ HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_GOOGLE, ++ USB_DEVICE_ID_GOOGLE_WHISKERS) }, + + /* Generic MT device */ + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) }, diff --git a/queue-5.10/kvm-ppc-book3s-hv-fix-incorrect-null-check-on-list-iterator.patch b/queue-5.10/kvm-ppc-book3s-hv-fix-incorrect-null-check-on-list-iterator.patch new file mode 100644 index 00000000000..53b279a5407 --- /dev/null +++ b/queue-5.10/kvm-ppc-book3s-hv-fix-incorrect-null-check-on-list-iterator.patch @@ -0,0 +1,51 @@ +From 300981abddcb13f8f06ad58f52358b53a8096775 Mon Sep 17 00:00:00 2001 +From: Xiaomeng Tong +Date: Thu, 14 Apr 2022 14:21:03 +0800 +Subject: KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator + +From: Xiaomeng Tong + +commit 300981abddcb13f8f06ad58f52358b53a8096775 upstream. + +The bug is here: + if (!p) + return ret; + +The list iterator value 'p' will *always* be set and non-NULL by +list_for_each_entry(), so it is incorrect to assume that the iterator +value will be NULL if the list is empty or no element is found. + +To fix the bug, Use a new value 'iter' as the list iterator, while use +the old value 'p' as a dedicated variable to point to the found element. + +Fixes: dfaa973ae960 ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate remaining normal-GFNs to secure-GFNs") +Cc: stable@vger.kernel.org # v5.9+ +Signed-off-by: Xiaomeng Tong +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220414062103.8153-1-xiam0nd.tong@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kvm/book3s_hv_uvmem.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/arch/powerpc/kvm/book3s_hv_uvmem.c ++++ b/arch/powerpc/kvm/book3s_hv_uvmem.c +@@ -359,13 +359,15 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsi + static bool kvmppc_next_nontransitioned_gfn(const struct kvm_memory_slot *memslot, + struct kvm *kvm, unsigned long *gfn) + { +- struct kvmppc_uvmem_slot *p; ++ struct kvmppc_uvmem_slot *p = NULL, *iter; + bool ret = false; + unsigned long i; + +- list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) +- if (*gfn >= p->base_pfn && *gfn < p->base_pfn + p->nr_pfns) ++ list_for_each_entry(iter, &kvm->arch.uvmem_pfns, list) ++ if (*gfn >= iter->base_pfn && *gfn < iter->base_pfn + iter->nr_pfns) { ++ p = iter; + break; ++ } + if (!p) + return ret; + /* diff --git a/queue-5.10/kvm-x86-avoid-calling-x86-emulator-without-a-decoded-instruction.patch b/queue-5.10/kvm-x86-avoid-calling-x86-emulator-without-a-decoded-instruction.patch new file mode 100644 index 00000000000..92bc9a77c6b --- /dev/null +++ b/queue-5.10/kvm-x86-avoid-calling-x86-emulator-without-a-decoded-instruction.patch @@ -0,0 +1,107 @@ +From fee060cd52d69c114b62d1a2948ea9648b5131f9 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 11 Mar 2022 03:27:41 +0000 +Subject: KVM: x86: avoid calling x86 emulator without a decoded instruction + +From: Sean Christopherson + +commit fee060cd52d69c114b62d1a2948ea9648b5131f9 upstream. + +Whenever x86_decode_emulated_instruction() detects a breakpoint, it +returns the value that kvm_vcpu_check_breakpoint() writes into its +pass-by-reference second argument. Unfortunately this is completely +bogus because the expected outcome of x86_decode_emulated_instruction +is an EMULATION_* value. + +Then, if kvm_vcpu_check_breakpoint() does "*r = 0" (corresponding to +a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK +and x86_emulate_instruction() is called without having decoded the +instruction. This causes various havoc from running with a stale +emulation context. + +The fix is to move the call to kvm_vcpu_check_breakpoint() where it was +before commit 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction +emulation with decoding") introduced x86_decode_emulated_instruction(). +The other caller of the function does not need breakpoint checks, +because it is invoked as part of a vmexit and the processor has already +checked those before executing the instruction that #GP'd. + +This fixes CVE-2022-1852. + +Reported-by: Qiuhao Li +Reported-by: Gaoning Pan +Reported-by: Yongkang Jia +Fixes: 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with decoding") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20220311032801.3467418-2-seanjc@google.com> +[Rewrote commit message according to Qiuhao's report, since a patch + already existed to fix the bug. - Paolo] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/x86.c | 31 +++++++++++++++++++------------ + 1 file changed, 19 insertions(+), 12 deletions(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -7295,7 +7295,7 @@ int kvm_skip_emulated_instruction(struct + } + EXPORT_SYMBOL_GPL(kvm_skip_emulated_instruction); + +-static bool kvm_vcpu_check_breakpoint(struct kvm_vcpu *vcpu, int *r) ++static bool kvm_vcpu_check_code_breakpoint(struct kvm_vcpu *vcpu, int *r) + { + if (unlikely(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) && + (vcpu->arch.guest_debug_dr7 & DR7_BP_EN_MASK)) { +@@ -7364,25 +7364,23 @@ static bool is_vmware_backdoor_opcode(st + } + + /* +- * Decode to be emulated instruction. Return EMULATION_OK if success. ++ * Decode an instruction for emulation. The caller is responsible for handling ++ * code breakpoints. Note, manually detecting code breakpoints is unnecessary ++ * (and wrong) when emulating on an intercepted fault-like exception[*], as ++ * code breakpoints have higher priority and thus have already been done by ++ * hardware. ++ * ++ * [*] Except #MC, which is higher priority, but KVM should never emulate in ++ * response to a machine check. + */ + int x86_decode_emulated_instruction(struct kvm_vcpu *vcpu, int emulation_type, + void *insn, int insn_len) + { +- int r = EMULATION_OK; + struct x86_emulate_ctxt *ctxt = vcpu->arch.emulate_ctxt; ++ int r; + + init_emulate_ctxt(vcpu); + +- /* +- * We will reenter on the same instruction since we do not set +- * complete_userspace_io. This does not handle watchpoints yet, +- * those would be handled in the emulate_ops. +- */ +- if (!(emulation_type & EMULTYPE_SKIP) && +- kvm_vcpu_check_breakpoint(vcpu, &r)) +- return r; +- + ctxt->ud = emulation_type & EMULTYPE_TRAP_UD; + + r = x86_decode_insn(ctxt, insn, insn_len); +@@ -7417,6 +7415,15 @@ int x86_emulate_instruction(struct kvm_v + if (!(emulation_type & EMULTYPE_NO_DECODE)) { + kvm_clear_exception_queue(vcpu); + ++ /* ++ * Return immediately if RIP hits a code breakpoint, such #DBs ++ * are fault-like and are higher priority than any faults on ++ * the code fetch itself. ++ */ ++ if (!(emulation_type & EMULTYPE_SKIP) && ++ kvm_vcpu_check_code_breakpoint(vcpu, &r)) ++ return r; ++ + r = x86_decode_emulated_instruction(vcpu, emulation_type, + insn, insn_len); + if (r != EMULATION_OK) { diff --git a/queue-5.10/lib-crypto-add-prompts-back-to-crypto-libraries.patch b/queue-5.10/lib-crypto-add-prompts-back-to-crypto-libraries.patch new file mode 100644 index 00000000000..476f06d74c1 --- /dev/null +++ b/queue-5.10/lib-crypto-add-prompts-back-to-crypto-libraries.patch @@ -0,0 +1,114 @@ +From foo@baz Fri Jun 3 04:46:19 PM CEST 2022 +From: "Jason A. Donenfeld" +Date: Thu, 2 Jun 2022 22:22:28 +0200 +Subject: lib/crypto: add prompts back to crypto libraries +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Message-ID: <20220602202232.281326-2-Jason@zx2c4.com> + +From: "Justin M. Forbes" + +commit e56e18985596617ae426ed5997fb2e737cffb58b upstream. + +Commit 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") took +away a number of prompt texts from other crypto libraries. This makes +values flip from built-in to module when oldconfig runs, and causes +problems when these crypto libs need to be built in for thingslike +BIG_KEYS. + +Fixes: 6048fdcc5f269 ("lib/crypto: blake2s: include as built-in") +Cc: Herbert Xu +Cc: linux-crypto@vger.kernel.org +Signed-off-by: Justin M. Forbes +[Jason: - moved menu into submenu of lib/ instead of root menu + - fixed chacha sub-dependencies for CONFIG_CRYPTO] +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + crypto/Kconfig | 2 -- + lib/Kconfig | 2 ++ + lib/crypto/Kconfig | 17 ++++++++++++----- + 3 files changed, 14 insertions(+), 7 deletions(-) + +--- a/crypto/Kconfig ++++ b/crypto/Kconfig +@@ -1941,5 +1941,3 @@ source "crypto/asymmetric_keys/Kconfig" + source "certs/Kconfig" + + endif # if CRYPTO +- +-source "lib/crypto/Kconfig" +--- a/lib/Kconfig ++++ b/lib/Kconfig +@@ -101,6 +101,8 @@ config INDIRECT_PIO + + When in doubt, say N. + ++source "lib/crypto/Kconfig" ++ + config CRC_CCITT + tristate "CRC-CCITT functions" + help +--- a/lib/crypto/Kconfig ++++ b/lib/crypto/Kconfig +@@ -1,5 +1,7 @@ + # SPDX-License-Identifier: GPL-2.0 + ++menu "Crypto library routines" ++ + config CRYPTO_LIB_AES + tristate + +@@ -31,7 +33,7 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA + + config CRYPTO_LIB_CHACHA_GENERIC + tristate +- select CRYPTO_ALGAPI ++ select XOR_BLOCKS + help + This symbol can be depended upon by arch implementations of the + ChaCha library interface that require the generic code as a +@@ -40,7 +42,8 @@ config CRYPTO_LIB_CHACHA_GENERIC + of CRYPTO_LIB_CHACHA. + + config CRYPTO_LIB_CHACHA +- tristate ++ tristate "ChaCha library interface" ++ depends on CRYPTO + depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA + select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=n + help +@@ -65,7 +68,7 @@ config CRYPTO_LIB_CURVE25519_GENERIC + of CRYPTO_LIB_CURVE25519. + + config CRYPTO_LIB_CURVE25519 +- tristate ++ tristate "Curve25519 scalar multiplication library" + depends on CRYPTO_ARCH_HAVE_LIB_CURVE25519 || !CRYPTO_ARCH_HAVE_LIB_CURVE25519 + select CRYPTO_LIB_CURVE25519_GENERIC if CRYPTO_ARCH_HAVE_LIB_CURVE25519=n + help +@@ -100,7 +103,7 @@ config CRYPTO_LIB_POLY1305_GENERIC + of CRYPTO_LIB_POLY1305. + + config CRYPTO_LIB_POLY1305 +- tristate ++ tristate "Poly1305 library interface" + depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 + select CRYPTO_LIB_POLY1305_GENERIC if CRYPTO_ARCH_HAVE_LIB_POLY1305=n + help +@@ -109,11 +112,15 @@ config CRYPTO_LIB_POLY1305 + is available and enabled. + + config CRYPTO_LIB_CHACHA20POLY1305 +- tristate ++ tristate "ChaCha20-Poly1305 AEAD support (8-byte nonce library version)" + depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA + depends on CRYPTO_ARCH_HAVE_LIB_POLY1305 || !CRYPTO_ARCH_HAVE_LIB_POLY1305 ++ depends on CRYPTO + select CRYPTO_LIB_CHACHA + select CRYPTO_LIB_POLY1305 ++ select CRYPTO_ALGAPI + + config CRYPTO_LIB_SHA256 + tristate ++ ++endmenu diff --git a/queue-5.10/net-ipa-compute-proper-aggregation-limit.patch b/queue-5.10/net-ipa-compute-proper-aggregation-limit.patch new file mode 100644 index 00000000000..41ef3f86c84 --- /dev/null +++ b/queue-5.10/net-ipa-compute-proper-aggregation-limit.patch @@ -0,0 +1,48 @@ +From c5794097b269f15961ed78f7f27b50e51766dec9 Mon Sep 17 00:00:00 2001 +From: Alex Elder +Date: Thu, 21 Apr 2022 13:53:33 -0500 +Subject: net: ipa: compute proper aggregation limit + +From: Alex Elder + +commit c5794097b269f15961ed78f7f27b50e51766dec9 upstream. + +The aggregation byte limit for an endpoint is currently computed +based on the endpoint's receive buffer size. + +However, some bytes at the front of each receive buffer are reserved +on the assumption that--as with SKBs--it might be useful to insert +data (such as headers) before what lands in the buffer. + +The aggregation byte limit currently doesn't take into account that +reserved space, and as a result, aggregation could require space +past that which is available in the buffer. + +Fix this by reducing the size used to compute the aggregation byte +limit by the NET_SKB_PAD offset reserved for each receive buffer. + +Signed-off-by: Alex Elder +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ipa/ipa_endpoint.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/ipa/ipa_endpoint.c ++++ b/drivers/net/ipa/ipa_endpoint.c +@@ -610,12 +610,14 @@ static void ipa_endpoint_init_aggr(struc + + if (endpoint->data->aggregation) { + if (!endpoint->toward_ipa) { ++ u32 buffer_size; + u32 limit; + + val |= u32_encode_bits(IPA_ENABLE_AGGR, AGGR_EN_FMASK); + val |= u32_encode_bits(IPA_GENERIC, AGGR_TYPE_FMASK); + +- limit = ipa_aggr_size_kb(IPA_RX_BUFFER_SIZE); ++ buffer_size = IPA_RX_BUFFER_SIZE - NET_SKB_PAD; ++ limit = ipa_aggr_size_kb(buffer_size); + val |= u32_encode_bits(limit, AGGR_BYTE_LIMIT_FMASK); + + limit = IPA_AGGR_TIME_LIMIT_DEFAULT; diff --git a/queue-5.10/netfilter-conntrack-re-fetch-conntrack-after-insertion.patch b/queue-5.10/netfilter-conntrack-re-fetch-conntrack-after-insertion.patch new file mode 100644 index 00000000000..2ac9e9640d0 --- /dev/null +++ b/queue-5.10/netfilter-conntrack-re-fetch-conntrack-after-insertion.patch @@ -0,0 +1,43 @@ +From 56b14ecec97f39118bf85c9ac2438c5a949509ed Mon Sep 17 00:00:00 2001 +From: Florian Westphal +Date: Fri, 20 May 2022 00:02:04 +0200 +Subject: netfilter: conntrack: re-fetch conntrack after insertion + +From: Florian Westphal + +commit 56b14ecec97f39118bf85c9ac2438c5a949509ed upstream. + +In case the conntrack is clashing, insertion can free skb->_nfct and +set skb->_nfct to the already-confirmed entry. + +This wasn't found before because the conntrack entry and the extension +space used to free'd after an rcu grace period, plus the race needs +events enabled to trigger. + +Reported-by: +Fixes: 71d8c47fc653 ("netfilter: conntrack: introduce clash resolution on insertion race") +Fixes: 2ad9d7747c10 ("netfilter: conntrack: free extension area immediately") +Signed-off-by: Florian Westphal +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman +--- + include/net/netfilter/nf_conntrack_core.h | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/include/net/netfilter/nf_conntrack_core.h ++++ b/include/net/netfilter/nf_conntrack_core.h +@@ -59,8 +59,13 @@ static inline int nf_conntrack_confirm(s + int ret = NF_ACCEPT; + + if (ct) { +- if (!nf_ct_is_confirmed(ct)) ++ if (!nf_ct_is_confirmed(ct)) { + ret = __nf_conntrack_confirm(skb); ++ ++ if (ret == NF_ACCEPT) ++ ct = (struct nf_conn *)skb_nfct(skb); ++ } ++ + if (likely(ret == NF_ACCEPT)) + nf_ct_deliver_cached_events(ct); + } diff --git a/queue-5.10/netfilter-nf_tables-sanitize-nft_set_desc_concat_parse.patch b/queue-5.10/netfilter-nf_tables-sanitize-nft_set_desc_concat_parse.patch new file mode 100644 index 00000000000..093cab01125 --- /dev/null +++ b/queue-5.10/netfilter-nf_tables-sanitize-nft_set_desc_concat_parse.patch @@ -0,0 +1,74 @@ +From fecf31ee395b0295f2d7260aa29946b7605f7c85 Mon Sep 17 00:00:00 2001 +From: Pablo Neira Ayuso +Date: Fri, 27 May 2022 09:56:18 +0200 +Subject: netfilter: nf_tables: sanitize nft_set_desc_concat_parse() + +From: Pablo Neira Ayuso + +commit fecf31ee395b0295f2d7260aa29946b7605f7c85 upstream. + +Add several sanity checks for nft_set_desc_concat_parse(): + +- validate desc->field_count not larger than desc->field_len array. +- field length cannot be larger than desc->field_len (ie. U8_MAX) +- total length of the concatenation cannot be larger than register array. + +Joint work with Florian Westphal. + +Fixes: f3a2181e16f1 ("netfilter: nf_tables: Support for sets with multiple ranged fields") +Reported-by: +Reviewed-by: Stefano Brivio +Signed-off-by: Florian Westphal +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman +--- + net/netfilter/nf_tables_api.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +--- a/net/netfilter/nf_tables_api.c ++++ b/net/netfilter/nf_tables_api.c +@@ -4051,6 +4051,9 @@ static int nft_set_desc_concat_parse(con + u32 len; + int err; + ++ if (desc->field_count >= ARRAY_SIZE(desc->field_len)) ++ return -E2BIG; ++ + err = nla_parse_nested_deprecated(tb, NFTA_SET_FIELD_MAX, attr, + nft_concat_policy, NULL); + if (err < 0) +@@ -4060,9 +4063,8 @@ static int nft_set_desc_concat_parse(con + return -EINVAL; + + len = ntohl(nla_get_be32(tb[NFTA_SET_FIELD_LEN])); +- +- if (len * BITS_PER_BYTE / 32 > NFT_REG32_COUNT) +- return -E2BIG; ++ if (!len || len > U8_MAX) ++ return -EINVAL; + + desc->field_len[desc->field_count++] = len; + +@@ -4073,7 +4075,8 @@ static int nft_set_desc_concat(struct nf + const struct nlattr *nla) + { + struct nlattr *attr; +- int rem, err; ++ u32 num_regs = 0; ++ int rem, err, i; + + nla_for_each_nested(attr, nla, rem) { + if (nla_type(attr) != NFTA_LIST_ELEM) +@@ -4084,6 +4087,12 @@ static int nft_set_desc_concat(struct nf + return err; + } + ++ for (i = 0; i < desc->field_count; i++) ++ num_regs += DIV_ROUND_UP(desc->field_len[i], sizeof(u32)); ++ ++ if (num_regs > NFT_REG32_COUNT) ++ return -E2BIG; ++ + return 0; + } + diff --git a/queue-5.10/raid5-introduce-md_broken.patch b/queue-5.10/raid5-introduce-md_broken.patch new file mode 100644 index 00000000000..3037e1e6b96 --- /dev/null +++ b/queue-5.10/raid5-introduce-md_broken.patch @@ -0,0 +1,159 @@ +From 57668f0a4cc4083a120cc8c517ca0055c4543b59 Mon Sep 17 00:00:00 2001 +From: Mariusz Tkaczyk +Date: Tue, 22 Mar 2022 16:23:39 +0100 +Subject: raid5: introduce MD_BROKEN + +From: Mariusz Tkaczyk + +commit 57668f0a4cc4083a120cc8c517ca0055c4543b59 upstream. + +Raid456 module had allowed to achieve failed state. It was fixed by +fb73b357fb9 ("raid5: block failing device if raid will be failed"). +This fix introduces a bug, now if raid5 fails during IO, it may result +with a hung task without completion. Faulty flag on the device is +necessary to process all requests and is checked many times, mainly in +analyze_stripe(). +Allow to set faulty on drive again and set MD_BROKEN if raid is failed. + +As a result, this level is allowed to achieve failed state again, but +communication with userspace (via -EBUSY status) will be preserved. + +This restores possibility to fail array via #mdadm --set-faulty command +and will be fixed by additional verification on mdadm side. + +Reproduction steps: + mdadm -CR imsm -e imsm -n 3 /dev/nvme[0-2]n1 + mdadm -CR r5 -e imsm -l5 -n3 /dev/nvme[0-2]n1 --assume-clean + mkfs.xfs /dev/md126 -f + mount /dev/md126 /mnt/root/ + + fio --filename=/mnt/root/file --size=5GB --direct=1 --rw=randrw +--bs=64k --ioengine=libaio --iodepth=64 --runtime=240 --numjobs=4 +--time_based --group_reporting --name=throughput-test-job +--eta-newline=1 & + + echo 1 > /sys/block/nvme2n1/device/device/remove + echo 1 > /sys/block/nvme1n1/device/device/remove + + [ 1475.787779] Call Trace: + [ 1475.793111] __schedule+0x2a6/0x700 + [ 1475.799460] schedule+0x38/0xa0 + [ 1475.805454] raid5_get_active_stripe+0x469/0x5f0 [raid456] + [ 1475.813856] ? finish_wait+0x80/0x80 + [ 1475.820332] raid5_make_request+0x180/0xb40 [raid456] + [ 1475.828281] ? finish_wait+0x80/0x80 + [ 1475.834727] ? finish_wait+0x80/0x80 + [ 1475.841127] ? finish_wait+0x80/0x80 + [ 1475.847480] md_handle_request+0x119/0x190 + [ 1475.854390] md_make_request+0x8a/0x190 + [ 1475.861041] generic_make_request+0xcf/0x310 + [ 1475.868145] submit_bio+0x3c/0x160 + [ 1475.874355] iomap_dio_submit_bio.isra.20+0x51/0x60 + [ 1475.882070] iomap_dio_bio_actor+0x175/0x390 + [ 1475.889149] iomap_apply+0xff/0x310 + [ 1475.895447] ? iomap_dio_bio_actor+0x390/0x390 + [ 1475.902736] ? iomap_dio_bio_actor+0x390/0x390 + [ 1475.909974] iomap_dio_rw+0x2f2/0x490 + [ 1475.916415] ? iomap_dio_bio_actor+0x390/0x390 + [ 1475.923680] ? atime_needs_update+0x77/0xe0 + [ 1475.930674] ? xfs_file_dio_aio_read+0x6b/0xe0 [xfs] + [ 1475.938455] xfs_file_dio_aio_read+0x6b/0xe0 [xfs] + [ 1475.946084] xfs_file_read_iter+0xba/0xd0 [xfs] + [ 1475.953403] aio_read+0xd5/0x180 + [ 1475.959395] ? _cond_resched+0x15/0x30 + [ 1475.965907] io_submit_one+0x20b/0x3c0 + [ 1475.972398] __x64_sys_io_submit+0xa2/0x180 + [ 1475.979335] ? do_io_getevents+0x7c/0xc0 + [ 1475.986009] do_syscall_64+0x5b/0x1a0 + [ 1475.992419] entry_SYSCALL_64_after_hwframe+0x65/0xca + [ 1476.000255] RIP: 0033:0x7f11fc27978d + [ 1476.006631] Code: Bad RIP value. + [ 1476.073251] INFO: task fio:3877 blocked for more than 120 seconds. + +Cc: stable@vger.kernel.org +Fixes: fb73b357fb9 ("raid5: block failing device if raid will be failed") +Reviewd-by: Xiao Ni +Signed-off-by: Mariusz Tkaczyk +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid5.c | 47 ++++++++++++++++++++++------------------------- + 1 file changed, 22 insertions(+), 25 deletions(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -686,17 +686,17 @@ int raid5_calc_degraded(struct r5conf *c + return degraded; + } + +-static int has_failed(struct r5conf *conf) ++static bool has_failed(struct r5conf *conf) + { +- int degraded; ++ int degraded = conf->mddev->degraded; + +- if (conf->mddev->reshape_position == MaxSector) +- return conf->mddev->degraded > conf->max_degraded; ++ if (test_bit(MD_BROKEN, &conf->mddev->flags)) ++ return true; + +- degraded = raid5_calc_degraded(conf); +- if (degraded > conf->max_degraded) +- return 1; +- return 0; ++ if (conf->mddev->reshape_position != MaxSector) ++ degraded = raid5_calc_degraded(conf); ++ ++ return degraded > conf->max_degraded; + } + + struct stripe_head * +@@ -2877,34 +2877,31 @@ static void raid5_error(struct mddev *md + unsigned long flags; + pr_debug("raid456: error called\n"); + ++ pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n", ++ mdname(mddev), bdevname(rdev->bdev, b)); ++ + spin_lock_irqsave(&conf->device_lock, flags); ++ set_bit(Faulty, &rdev->flags); ++ clear_bit(In_sync, &rdev->flags); ++ mddev->degraded = raid5_calc_degraded(conf); + +- if (test_bit(In_sync, &rdev->flags) && +- mddev->degraded == conf->max_degraded) { +- /* +- * Don't allow to achieve failed state +- * Don't try to recover this device +- */ ++ if (has_failed(conf)) { ++ set_bit(MD_BROKEN, &conf->mddev->flags); + conf->recovery_disabled = mddev->recovery_disabled; +- spin_unlock_irqrestore(&conf->device_lock, flags); +- return; ++ ++ pr_crit("md/raid:%s: Cannot continue operation (%d/%d failed).\n", ++ mdname(mddev), mddev->degraded, conf->raid_disks); ++ } else { ++ pr_crit("md/raid:%s: Operation continuing on %d devices.\n", ++ mdname(mddev), conf->raid_disks - mddev->degraded); + } + +- set_bit(Faulty, &rdev->flags); +- clear_bit(In_sync, &rdev->flags); +- mddev->degraded = raid5_calc_degraded(conf); + spin_unlock_irqrestore(&conf->device_lock, flags); + set_bit(MD_RECOVERY_INTR, &mddev->recovery); + + set_bit(Blocked, &rdev->flags); + set_mask_bits(&mddev->sb_flags, 0, + BIT(MD_SB_CHANGE_DEVS) | BIT(MD_SB_CHANGE_PENDING)); +- pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n" +- "md/raid:%s: Operation continuing on %d devices.\n", +- mdname(mddev), +- bdevname(rdev->bdev, b), +- mdname(mddev), +- conf->raid_disks - mddev->degraded); + r5c_update_on_rdev_error(mddev, rdev); + } + diff --git a/queue-5.10/series b/queue-5.10/series index be09ec7802f..81a17af0e67 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -12,3 +12,35 @@ cfg80211-set-custom-regdomain-after-wiphy-registration.patch assoc_array-fix-bug_on-during-garbage-collect.patch io_uring-don-t-re-import-iovecs-from-callbacks.patch io_uring-fix-using-under-expanded-iters.patch +net-ipa-compute-proper-aggregation-limit.patch +xfs-detect-overflows-in-bmbt-records.patch +xfs-show-the-proper-user-quota-options.patch +xfs-fix-the-forward-progress-assertion-in-xfs_iwalk_run_callbacks.patch +xfs-fix-an-abba-deadlock-in-xfs_rename.patch +xfs-fix-cil-throttle-hang-when-cil-space-used-going-backwards.patch +drm-i915-fix-wstringop-overflow-warning-in-call-to-intel_read_wm_latency.patch +exfat-check-if-cluster-num-is-valid.patch +exfat-fix-referencing-wrong-parent-directory-information-after-renaming.patch +lib-crypto-add-prompts-back-to-crypto-libraries.patch +crypto-drbg-prepare-for-more-fine-grained-tracking-of-seeding-state.patch +crypto-drbg-track-whether-drbg-was-seeded-with-rng_is_initialized.patch +crypto-drbg-move-dynamic-reseed_threshold-adjustments-to-__drbg_seed.patch +crypto-drbg-make-reseeding-from-get_random_bytes-synchronous.patch +netfilter-nf_tables-sanitize-nft_set_desc_concat_parse.patch +netfilter-conntrack-re-fetch-conntrack-after-insertion.patch +kvm-ppc-book3s-hv-fix-incorrect-null-check-on-list-iterator.patch +x86-kvm-alloc-dummy-async-pf-token-outside-of-raw-spinlock.patch +x86-kvm-use-correct-gfp-flags-for-preemption-disabled.patch +kvm-x86-avoid-calling-x86-emulator-without-a-decoded-instruction.patch +crypto-caam-fix-i.mx6sx-entropy-delay-value.patch +crypto-ecrdsa-fix-incorrect-use-of-vli_cmp.patch +zsmalloc-fix-races-between-asynchronous-zspage-free-and-page-migration.patch +bluetooth-hci_qca-use-del_timer_sync-before-freeing.patch +arm-dts-s5pv210-correct-interrupt-name-for-bluetooth-in-aries.patch +dm-integrity-fix-error-code-in-dm_integrity_ctr.patch +dm-crypt-make-printing-of-the-key-constant-time.patch +dm-stats-add-cond_resched-when-looping-over-entries.patch +dm-verity-set-dm_target_immutable-feature-flag.patch +raid5-introduce-md_broken.patch +hid-multitouch-add-support-for-google-whiskers-touchpad.patch +hid-multitouch-add-quirks-to-enable-lenovo-x12-trackpoint.patch diff --git a/queue-5.10/x86-kvm-alloc-dummy-async-pf-token-outside-of-raw-spinlock.patch b/queue-5.10/x86-kvm-alloc-dummy-async-pf-token-outside-of-raw-spinlock.patch new file mode 100644 index 00000000000..6a191d0a399 --- /dev/null +++ b/queue-5.10/x86-kvm-alloc-dummy-async-pf-token-outside-of-raw-spinlock.patch @@ -0,0 +1,91 @@ +From 0547758a6de3cc71a0cfdd031a3621a30db6a68b Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 19 May 2022 07:57:11 -0700 +Subject: x86/kvm: Alloc dummy async #PF token outside of raw spinlock + +From: Sean Christopherson + +commit 0547758a6de3cc71a0cfdd031a3621a30db6a68b upstream. + +Drop the raw spinlock in kvm_async_pf_task_wake() before allocating the +the dummy async #PF token, the allocator is preemptible on PREEMPT_RT +kernels and must not be called from truly atomic contexts. + +Opportunistically document why it's ok to loop on allocation failure, +i.e. why the function won't get stuck in an infinite loop. + +Reported-by: Yajun Deng +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/kvm.c | 41 +++++++++++++++++++++++++++-------------- + 1 file changed, 27 insertions(+), 14 deletions(-) + +--- a/arch/x86/kernel/kvm.c ++++ b/arch/x86/kernel/kvm.c +@@ -188,7 +188,7 @@ void kvm_async_pf_task_wake(u32 token) + { + u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS); + struct kvm_task_sleep_head *b = &async_pf_sleepers[key]; +- struct kvm_task_sleep_node *n; ++ struct kvm_task_sleep_node *n, *dummy = NULL; + + if (token == ~0) { + apf_task_wake_all(); +@@ -200,28 +200,41 @@ again: + n = _find_apf_task(b, token); + if (!n) { + /* +- * async PF was not yet handled. +- * Add dummy entry for the token. ++ * Async #PF not yet handled, add a dummy entry for the token. ++ * Allocating the token must be down outside of the raw lock ++ * as the allocator is preemptible on PREEMPT_RT kernels. + */ +- n = kzalloc(sizeof(*n), GFP_ATOMIC); +- if (!n) { ++ if (!dummy) { ++ raw_spin_unlock(&b->lock); ++ dummy = kzalloc(sizeof(*dummy), GFP_KERNEL); ++ + /* +- * Allocation failed! Busy wait while other cpu +- * handles async PF. ++ * Continue looping on allocation failure, eventually ++ * the async #PF will be handled and allocating a new ++ * node will be unnecessary. ++ */ ++ if (!dummy) ++ cpu_relax(); ++ ++ /* ++ * Recheck for async #PF completion before enqueueing ++ * the dummy token to avoid duplicate list entries. + */ +- raw_spin_unlock(&b->lock); +- cpu_relax(); + goto again; + } +- n->token = token; +- n->cpu = smp_processor_id(); +- init_swait_queue_head(&n->wq); +- hlist_add_head(&n->link, &b->list); ++ dummy->token = token; ++ dummy->cpu = smp_processor_id(); ++ init_swait_queue_head(&dummy->wq); ++ hlist_add_head(&dummy->link, &b->list); ++ dummy = NULL; + } else { + apf_task_wake_one(n); + } + raw_spin_unlock(&b->lock); +- return; ++ ++ /* A dummy token might be allocated and ultimately not used. */ ++ if (dummy) ++ kfree(dummy); + } + EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake); + diff --git a/queue-5.10/x86-kvm-use-correct-gfp-flags-for-preemption-disabled.patch b/queue-5.10/x86-kvm-use-correct-gfp-flags-for-preemption-disabled.patch new file mode 100644 index 00000000000..e0c6c8d8851 --- /dev/null +++ b/queue-5.10/x86-kvm-use-correct-gfp-flags-for-preemption-disabled.patch @@ -0,0 +1,81 @@ +From baec4f5a018fe2d708fc1022330dba04b38b5fe3 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Tue, 24 May 2022 09:43:31 -0400 +Subject: x86, kvm: use correct GFP flags for preemption disabled + +From: Paolo Bonzini + +commit baec4f5a018fe2d708fc1022330dba04b38b5fe3 upstream. + +Commit ddd7ed842627 ("x86/kvm: Alloc dummy async #PF token outside of +raw spinlock") leads to the following Smatch static checker warning: + + arch/x86/kernel/kvm.c:212 kvm_async_pf_task_wake() + warn: sleeping in atomic context + +arch/x86/kernel/kvm.c + 202 raw_spin_lock(&b->lock); + 203 n = _find_apf_task(b, token); + 204 if (!n) { + 205 /* + 206 * Async #PF not yet handled, add a dummy entry for the token. + 207 * Allocating the token must be down outside of the raw lock + 208 * as the allocator is preemptible on PREEMPT_RT kernels. + 209 */ + 210 if (!dummy) { + 211 raw_spin_unlock(&b->lock); +--> 212 dummy = kzalloc(sizeof(*dummy), GFP_KERNEL); + ^^^^^^^^^^ +Smatch thinks the caller has preempt disabled. The `smdb.py preempt +kvm_async_pf_task_wake` output call tree is: + +sysvec_kvm_asyncpf_interrupt() <- disables preempt +-> __sysvec_kvm_asyncpf_interrupt() + -> kvm_async_pf_task_wake() + +The caller is this: + +arch/x86/kernel/kvm.c + 290 DEFINE_IDTENTRY_SYSVEC(sysvec_kvm_asyncpf_interrupt) + 291 { + 292 struct pt_regs *old_regs = set_irq_regs(regs); + 293 u32 token; + 294 + 295 ack_APIC_irq(); + 296 + 297 inc_irq_stat(irq_hv_callback_count); + 298 + 299 if (__this_cpu_read(apf_reason.enabled)) { + 300 token = __this_cpu_read(apf_reason.token); + 301 kvm_async_pf_task_wake(token); + 302 __this_cpu_write(apf_reason.token, 0); + 303 wrmsrl(MSR_KVM_ASYNC_PF_ACK, 1); + 304 } + 305 + 306 set_irq_regs(old_regs); + 307 } + +The DEFINE_IDTENTRY_SYSVEC() is a wrapper that calls this function +from the call_on_irqstack_cond(). It's inside the call_on_irqstack_cond() +where preempt is disabled (unless it's already disabled). The +irq_enter/exit_rcu() functions disable/enable preempt. + +Reported-by: Dan Carpenter +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/kvm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/kvm.c ++++ b/arch/x86/kernel/kvm.c +@@ -206,7 +206,7 @@ again: + */ + if (!dummy) { + raw_spin_unlock(&b->lock); +- dummy = kzalloc(sizeof(*dummy), GFP_KERNEL); ++ dummy = kzalloc(sizeof(*dummy), GFP_ATOMIC); + + /* + * Continue looping on allocation failure, eventually diff --git a/queue-5.10/xfs-detect-overflows-in-bmbt-records.patch b/queue-5.10/xfs-detect-overflows-in-bmbt-records.patch new file mode 100644 index 00000000000..0fb4bc1476b --- /dev/null +++ b/queue-5.10/xfs-detect-overflows-in-bmbt-records.patch @@ -0,0 +1,44 @@ +From foo@baz Fri Jun 3 04:32:03 PM CEST 2022 +From: Amir Goldstein +Date: Fri, 27 May 2022 16:02:15 +0300 +Subject: xfs: detect overflows in bmbt records +To: Greg Kroah-Hartman +Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org +Message-ID: <20220527130219.3110260-2-amir73il@gmail.com> + +From: "Darrick J. Wong" + +commit acf104c2331c1ba2a667e65dd36139d1555b1432 upstream. + +Detect file block mappings with a blockcount that's either so large that +integer overflows occur or are zero, because neither are valid in the +filesystem. Worse yet, attempting directory modifications causes the +iext code to trip over the bmbt key handling and takes the filesystem +down. We can fix most of this by preventing the bad metadata from +entering the incore structures in the first place. + +Found by setting blockcount=0 in a directory data fork mapping and +watching the fireworks. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Christoph Hellwig +Signed-off-by: Amir Goldstein +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/libxfs/xfs_bmap.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/xfs/libxfs/xfs_bmap.c ++++ b/fs/xfs/libxfs/xfs_bmap.c +@@ -6229,6 +6229,11 @@ xfs_bmap_validate_extent( + xfs_fsblock_t endfsb; + bool isrt; + ++ if (irec->br_startblock + irec->br_blockcount <= irec->br_startblock) ++ return __this_address; ++ if (irec->br_startoff + irec->br_blockcount <= irec->br_startoff) ++ return __this_address; ++ + isrt = XFS_IS_REALTIME_INODE(ip); + endfsb = irec->br_startblock + irec->br_blockcount - 1; + if (isrt && whichfork == XFS_DATA_FORK) { diff --git a/queue-5.10/xfs-fix-an-abba-deadlock-in-xfs_rename.patch b/queue-5.10/xfs-fix-an-abba-deadlock-in-xfs_rename.patch new file mode 100644 index 00000000000..11e85078364 --- /dev/null +++ b/queue-5.10/xfs-fix-an-abba-deadlock-in-xfs_rename.patch @@ -0,0 +1,126 @@ +From foo@baz Fri Jun 3 04:32:03 PM CEST 2022 +From: Amir Goldstein +Date: Fri, 27 May 2022 16:02:18 +0300 +Subject: xfs: fix an ABBA deadlock in xfs_rename +To: Greg Kroah-Hartman +Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, wenli xie , Brian Foster +Message-ID: <20220527130219.3110260-5-amir73il@gmail.com> + +From: "Darrick J. Wong" + +commit 6da1b4b1ab36d80a3994fd4811c8381de10af604 upstream. + +When overlayfs is running on top of xfs and the user unlinks a file in +the overlay, overlayfs will create a whiteout inode and ask xfs to +"rename" the whiteout file atop the one being unlinked. If the file +being unlinked loses its one nlink, we then have to put the inode on the +unlinked list. + +This requires us to grab the AGI buffer of the whiteout inode to take it +off the unlinked list (which is where whiteouts are created) and to grab +the AGI buffer of the file being deleted. If the whiteout was created +in a higher numbered AG than the file being deleted, we'll lock the AGIs +in the wrong order and deadlock. + +Therefore, grab all the AGI locks we think we'll need ahead of time, and +in order of increasing AG number per the locking rules. + +Reported-by: wenli xie +Fixes: 93597ae8dac0 ("xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename()") +Signed-off-by: Darrick J. Wong +Reviewed-by: Brian Foster +Signed-off-by: Amir Goldstein +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/libxfs/xfs_dir2.h | 2 -- + fs/xfs/libxfs/xfs_dir2_sf.c | 2 +- + fs/xfs/xfs_inode.c | 42 +++++++++++++++++++++++++----------------- + 3 files changed, 26 insertions(+), 20 deletions(-) + +--- a/fs/xfs/libxfs/xfs_dir2.h ++++ b/fs/xfs/libxfs/xfs_dir2.h +@@ -47,8 +47,6 @@ extern int xfs_dir_lookup(struct xfs_tra + extern int xfs_dir_removename(struct xfs_trans *tp, struct xfs_inode *dp, + struct xfs_name *name, xfs_ino_t ino, + xfs_extlen_t tot); +-extern bool xfs_dir2_sf_replace_needblock(struct xfs_inode *dp, +- xfs_ino_t inum); + extern int xfs_dir_replace(struct xfs_trans *tp, struct xfs_inode *dp, + struct xfs_name *name, xfs_ino_t inum, + xfs_extlen_t tot); +--- a/fs/xfs/libxfs/xfs_dir2_sf.c ++++ b/fs/xfs/libxfs/xfs_dir2_sf.c +@@ -1018,7 +1018,7 @@ xfs_dir2_sf_removename( + /* + * Check whether the sf dir replace operation need more blocks. + */ +-bool ++static bool + xfs_dir2_sf_replace_needblock( + struct xfs_inode *dp, + xfs_ino_t inum) +--- a/fs/xfs/xfs_inode.c ++++ b/fs/xfs/xfs_inode.c +@@ -3152,7 +3152,7 @@ xfs_rename( + struct xfs_trans *tp; + struct xfs_inode *wip = NULL; /* whiteout inode */ + struct xfs_inode *inodes[__XFS_SORT_INODES]; +- struct xfs_buf *agibp; ++ int i; + int num_inodes = __XFS_SORT_INODES; + bool new_parent = (src_dp != target_dp); + bool src_is_directory = S_ISDIR(VFS_I(src_ip)->i_mode); +@@ -3266,6 +3266,30 @@ xfs_rename( + } + + /* ++ * Lock the AGI buffers we need to handle bumping the nlink of the ++ * whiteout inode off the unlinked list and to handle dropping the ++ * nlink of the target inode. Per locking order rules, do this in ++ * increasing AG order and before directory block allocation tries to ++ * grab AGFs because we grab AGIs before AGFs. ++ * ++ * The (vfs) caller must ensure that if src is a directory then ++ * target_ip is either null or an empty directory. ++ */ ++ for (i = 0; i < num_inodes && inodes[i] != NULL; i++) { ++ if (inodes[i] == wip || ++ (inodes[i] == target_ip && ++ (VFS_I(target_ip)->i_nlink == 1 || src_is_directory))) { ++ struct xfs_buf *bp; ++ xfs_agnumber_t agno; ++ ++ agno = XFS_INO_TO_AGNO(mp, inodes[i]->i_ino); ++ error = xfs_read_agi(mp, tp, agno, &bp); ++ if (error) ++ goto out_trans_cancel; ++ } ++ } ++ ++ /* + * Directory entry creation below may acquire the AGF. Remove + * the whiteout from the unlinked list first to preserve correct + * AGI/AGF locking order. This dirties the transaction so failures +@@ -3317,22 +3341,6 @@ xfs_rename( + * In case there is already an entry with the same + * name at the destination directory, remove it first. + */ +- +- /* +- * Check whether the replace operation will need to allocate +- * blocks. This happens when the shortform directory lacks +- * space and we have to convert it to a block format directory. +- * When more blocks are necessary, we must lock the AGI first +- * to preserve locking order (AGI -> AGF). +- */ +- if (xfs_dir2_sf_replace_needblock(target_dp, src_ip->i_ino)) { +- error = xfs_read_agi(mp, tp, +- XFS_INO_TO_AGNO(mp, target_ip->i_ino), +- &agibp); +- if (error) +- goto out_trans_cancel; +- } +- + error = xfs_dir_replace(tp, target_dp, target_name, + src_ip->i_ino, spaceres); + if (error) diff --git a/queue-5.10/xfs-fix-cil-throttle-hang-when-cil-space-used-going-backwards.patch b/queue-5.10/xfs-fix-cil-throttle-hang-when-cil-space-used-going-backwards.patch new file mode 100644 index 00000000000..8b50ccd1af8 --- /dev/null +++ b/queue-5.10/xfs-fix-cil-throttle-hang-when-cil-space-used-going-backwards.patch @@ -0,0 +1,259 @@ +From foo@baz Fri Jun 3 04:32:03 PM CEST 2022 +From: Amir Goldstein +Date: Fri, 27 May 2022 16:02:19 +0300 +Subject: xfs: Fix CIL throttle hang when CIL space used going backwards +To: Greg Kroah-Hartman +Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Donald Buczek , Brian Foster , Chandan Babu R , "Darrick J . Wong" , Allison Henderson +Message-ID: <20220527130219.3110260-6-amir73il@gmail.com> + +From: Dave Chinner + +commit 19f4e7cc819771812a7f527d7897c2deffbf7a00 upstream. + +A hang with tasks stuck on the CIL hard throttle was reported and +largely diagnosed by Donald Buczek, who discovered that it was a +result of the CIL context space usage decrementing in committed +transactions once the hard throttle limit had been hit and processes +were already blocked. This resulted in the CIL push not waking up +those waiters because the CIL context was no longer over the hard +throttle limit. + +The surprising aspect of this was the CIL space usage going +backwards regularly enough to trigger this situation. Assumptions +had been made in design that the relogging process would only +increase the size of the objects in the CIL, and so that space would +only increase. + +This change and commit message fixes the issue and documents the +result of an audit of the triggers that can cause the CIL space to +go backwards, how large the backwards steps tend to be, the +frequency in which they occur, and what the impact on the CIL +accounting code is. + +Even though the CIL ctx->space_used can go backwards, it will only +do so if the log item is already logged to the CIL and contains a +space reservation for it's entire logged state. This is tracked by +the shadow buffer state on the log item. If the item is not +previously logged in the CIL it has no shadow buffer nor log vector, +and hence the entire size of the logged item copied to the log +vector is accounted to the CIL space usage. i.e. it will always go +up in this case. + +If the item has a log vector (i.e. already in the CIL) and the size +decreases, then the existing log vector will be overwritten and the +space usage will go down. This is the only condition where the space +usage reduces, and it can only occur when an item is already tracked +in the CIL. Hence we are safe from CIL space usage underruns as a +result of log items decreasing in size when they are relogged. + +Typically this reduction in CIL usage occurs from metadata blocks +being free, such as when a btree block merge occurs or a directory +enter/xattr entry is removed and the da-tree is reduced in size. +This generally results in a reduction in size of around a single +block in the CIL, but also tends to increase the number of log +vectors because the parent and sibling nodes in the tree needs to be +updated when a btree block is removed. If a multi-level merge +occurs, then we see reduction in size of 2+ blocks, but again the +log vector count goes up. + +The other vector is inode fork size changes, which only log the +current size of the fork and ignore the previously logged size when +the fork is relogged. Hence if we are removing items from the inode +fork (dir/xattr removal in shortform, extent record removal in +extent form, etc) the relogged size of the inode for can decrease. + +No other log items can decrease in size either because they are a +fixed size (e.g. dquots) or they cannot be relogged (e.g. relogging +an intent actually creates a new intent log item and doesn't relog +the old item at all.) Hence the only two vectors for CIL context +size reduction are relogging inode forks and marking buffers active +in the CIL as stale. + +Long story short: the majority of the code does the right thing and +handles the reduction in log item size correctly, and only the CIL +hard throttle implementation is problematic and needs fixing. This +patch makes that fix, as well as adds comments in the log item code +that result in items shrinking in size when they are relogged as a +clear reminder that this can and does happen frequently. + +The throttle fix is based upon the change Donald proposed, though it +goes further to ensure that once the throttle is activated, it +captures all tasks until the CIL push issues a wakeup, regardless of +whether the CIL space used has gone back under the throttle +threshold. + +This ensures that we prevent tasks reducing the CIL slightly under +the throttle threshold and then making more changes that push it +well over the throttle limit. This is acheived by checking if the +throttle wait queue is already active as a condition of throttling. +Hence once we start throttling, we continue to apply the throttle +until the CIL context push wakes everything on the wait queue. + +We can use waitqueue_active() for the waitqueue manipulations and +checks as they are all done under the ctx->xc_push_lock. Hence the +waitqueue has external serialisation and we can safely peek inside +the wait queue without holding the internal waitqueue locks. + +Many thanks to Donald for his diagnostic and analysis work to +isolate the cause of this hang. + +Reported-and-tested-by: Donald Buczek +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Reviewed-by: Chandan Babu R +Reviewed-by: Darrick J. Wong +Reviewed-by: Allison Henderson +Signed-off-by: Darrick J. Wong +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_buf_item.c | 37 ++++++++++++++++++------------------- + fs/xfs/xfs_inode_item.c | 14 ++++++++++++++ + fs/xfs/xfs_log_cil.c | 22 +++++++++++++++++----- + 3 files changed, 49 insertions(+), 24 deletions(-) + +--- a/fs/xfs/xfs_buf_item.c ++++ b/fs/xfs/xfs_buf_item.c +@@ -56,14 +56,12 @@ xfs_buf_log_format_size( + } + + /* +- * This returns the number of log iovecs needed to log the +- * given buf log item. ++ * Return the number of log iovecs and space needed to log the given buf log ++ * item segment. + * +- * It calculates this as 1 iovec for the buf log format structure +- * and 1 for each stretch of non-contiguous chunks to be logged. +- * Contiguous chunks are logged in a single iovec. +- * +- * If the XFS_BLI_STALE flag has been set, then log nothing. ++ * It calculates this as 1 iovec for the buf log format structure and 1 for each ++ * stretch of non-contiguous chunks to be logged. Contiguous chunks are logged ++ * in a single iovec. + */ + STATIC void + xfs_buf_item_size_segment( +@@ -119,11 +117,8 @@ xfs_buf_item_size_segment( + } + + /* +- * This returns the number of log iovecs needed to log the given buf log item. +- * +- * It calculates this as 1 iovec for the buf log format structure and 1 for each +- * stretch of non-contiguous chunks to be logged. Contiguous chunks are logged +- * in a single iovec. ++ * Return the number of log iovecs and space needed to log the given buf log ++ * item. + * + * Discontiguous buffers need a format structure per region that is being + * logged. This makes the changes in the buffer appear to log recovery as though +@@ -133,7 +128,11 @@ xfs_buf_item_size_segment( + * what ends up on disk. + * + * If the XFS_BLI_STALE flag has been set, then log nothing but the buf log +- * format structures. ++ * format structures. If the item has previously been logged and has dirty ++ * regions, we do not relog them in stale buffers. This has the effect of ++ * reducing the size of the relogged item by the amount of dirty data tracked ++ * by the log item. This can result in the committing transaction reducing the ++ * amount of space being consumed by the CIL. + */ + STATIC void + xfs_buf_item_size( +@@ -147,9 +146,9 @@ xfs_buf_item_size( + ASSERT(atomic_read(&bip->bli_refcount) > 0); + if (bip->bli_flags & XFS_BLI_STALE) { + /* +- * The buffer is stale, so all we need to log +- * is the buf log format structure with the +- * cancel flag in it. ++ * The buffer is stale, so all we need to log is the buf log ++ * format structure with the cancel flag in it as we are never ++ * going to replay the changes tracked in the log item. + */ + trace_xfs_buf_item_size_stale(bip); + ASSERT(bip->__bli_format.blf_flags & XFS_BLF_CANCEL); +@@ -164,9 +163,9 @@ xfs_buf_item_size( + + if (bip->bli_flags & XFS_BLI_ORDERED) { + /* +- * The buffer has been logged just to order it. +- * It is not being included in the transaction +- * commit, so no vectors are used at all. ++ * The buffer has been logged just to order it. It is not being ++ * included in the transaction commit, so no vectors are used at ++ * all. + */ + trace_xfs_buf_item_size_ordered(bip); + *nvecs = XFS_LOG_VEC_ORDERED; +--- a/fs/xfs/xfs_inode_item.c ++++ b/fs/xfs/xfs_inode_item.c +@@ -28,6 +28,20 @@ static inline struct xfs_inode_log_item + return container_of(lip, struct xfs_inode_log_item, ili_item); + } + ++/* ++ * The logged size of an inode fork is always the current size of the inode ++ * fork. This means that when an inode fork is relogged, the size of the logged ++ * region is determined by the current state, not the combination of the ++ * previously logged state + the current state. This is different relogging ++ * behaviour to most other log items which will retain the size of the ++ * previously logged changes when smaller regions are relogged. ++ * ++ * Hence operations that remove data from the inode fork (e.g. shortform ++ * dir/attr remove, extent form extent removal, etc), the size of the relogged ++ * inode gets -smaller- rather than stays the same size as the previously logged ++ * size and this can result in the committing transaction reducing the amount of ++ * space being consumed by the CIL. ++ */ + STATIC void + xfs_inode_item_data_fork_size( + struct xfs_inode_log_item *iip, +--- a/fs/xfs/xfs_log_cil.c ++++ b/fs/xfs/xfs_log_cil.c +@@ -668,9 +668,14 @@ xlog_cil_push_work( + ASSERT(push_seq <= ctx->sequence); + + /* +- * Wake up any background push waiters now this context is being pushed. ++ * As we are about to switch to a new, empty CIL context, we no longer ++ * need to throttle tasks on CIL space overruns. Wake any waiters that ++ * the hard push throttle may have caught so they can start committing ++ * to the new context. The ctx->xc_push_lock provides the serialisation ++ * necessary for safely using the lockless waitqueue_active() check in ++ * this context. + */ +- if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) ++ if (waitqueue_active(&cil->xc_push_wait)) + wake_up_all(&cil->xc_push_wait); + + /* +@@ -907,7 +912,7 @@ xlog_cil_push_background( + ASSERT(!list_empty(&cil->xc_cil)); + + /* +- * don't do a background push if we haven't used up all the ++ * Don't do a background push if we haven't used up all the + * space available yet. + */ + if (cil->xc_ctx->space_used < XLOG_CIL_SPACE_LIMIT(log)) { +@@ -931,9 +936,16 @@ xlog_cil_push_background( + + /* + * If we are well over the space limit, throttle the work that is being +- * done until the push work on this context has begun. ++ * done until the push work on this context has begun. Enforce the hard ++ * throttle on all transaction commits once it has been activated, even ++ * if the committing transactions have resulted in the space usage ++ * dipping back down under the hard limit. ++ * ++ * The ctx->xc_push_lock provides the serialisation necessary for safely ++ * using the lockless waitqueue_active() check in this context. + */ +- if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) { ++ if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log) || ++ waitqueue_active(&cil->xc_push_wait)) { + trace_xfs_log_cil_wait(log, cil->xc_ctx->ticket); + ASSERT(cil->xc_ctx->space_used < log->l_logsize); + xlog_wait(&cil->xc_push_wait, &cil->xc_push_lock); diff --git a/queue-5.10/xfs-fix-the-forward-progress-assertion-in-xfs_iwalk_run_callbacks.patch b/queue-5.10/xfs-fix-the-forward-progress-assertion-in-xfs_iwalk_run_callbacks.patch new file mode 100644 index 00000000000..7444a4a00ce --- /dev/null +++ b/queue-5.10/xfs-fix-the-forward-progress-assertion-in-xfs_iwalk_run_callbacks.patch @@ -0,0 +1,42 @@ +From foo@baz Fri Jun 3 04:32:03 PM CEST 2022 +From: Amir Goldstein +Date: Fri, 27 May 2022 16:02:17 +0300 +Subject: xfs: fix the forward progress assertion in xfs_iwalk_run_callbacks +To: Greg Kroah-Hartman +Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, zlang@redhat.com, Dave Chinner +Message-ID: <20220527130219.3110260-4-amir73il@gmail.com> + +From: "Darrick J. Wong" + +commit a5336d6bb2d02d0e9d4d3c8be04b80b8b68d56c8 upstream. + +In commit 27c14b5daa82 we started tracking the last inode seen during an +inode walk to avoid infinite loops if a corrupt inobt record happens to +have a lower ir_startino than the record preceeding it. Unfortunately, +the assertion trips over the case where there are completely empty inobt +records (which can happen quite easily on 64k page filesystems) because +we advance the tracking cursor without actually putting the empty record +into the processing buffer. Fix the assert to allow for this case. + +Reported-by: zlang@redhat.com +Fixes: 27c14b5daa82 ("xfs: ensure inobt record walks always make forward progress") +Signed-off-by: Darrick J. Wong +Reviewed-by: Zorro Lang +Reviewed-by: Dave Chinner +Signed-off-by: Amir Goldstein +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_iwalk.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/xfs/xfs_iwalk.c ++++ b/fs/xfs/xfs_iwalk.c +@@ -363,7 +363,7 @@ xfs_iwalk_run_callbacks( + /* Delete cursor but remember the last record we cached... */ + xfs_iwalk_del_inobt(tp, curpp, agi_bpp, 0); + irec = &iwag->recs[iwag->nr_recs - 1]; +- ASSERT(next_agino == irec->ir_startino + XFS_INODES_PER_CHUNK); ++ ASSERT(next_agino >= irec->ir_startino + XFS_INODES_PER_CHUNK); + + error = xfs_iwalk_ag_recs(iwag); + if (error) diff --git a/queue-5.10/xfs-show-the-proper-user-quota-options.patch b/queue-5.10/xfs-show-the-proper-user-quota-options.patch new file mode 100644 index 00000000000..787f805bc59 --- /dev/null +++ b/queue-5.10/xfs-show-the-proper-user-quota-options.patch @@ -0,0 +1,45 @@ +From foo@baz Fri Jun 3 04:32:03 PM CEST 2022 +From: Amir Goldstein +Date: Fri, 27 May 2022 16:02:16 +0300 +Subject: xfs: show the proper user quota options +To: Greg Kroah-Hartman +Cc: Sasha Levin , Dave Chinner , "Darrick J . Wong" , Christoph Hellwig , Luis Chamberlain , Theodore Ts'o , Leah Rumancik , Chandan Babu R , Adam Manzanares , Tyler Hicks , Jan Kara , linux-xfs@vger.kernel.org, stable@vger.kernel.org, Kaixu Xia +Message-ID: <20220527130219.3110260-3-amir73il@gmail.com> + +From: Kaixu Xia + +commit 237d7887ae723af7d978e8b9a385fdff416f357b upstream. + +The quota option 'usrquota' should be shown if both the XFS_UQUOTA_ACCT +and XFS_UQUOTA_ENFD flags are set. The option 'uqnoenforce' should be +shown when only the XFS_UQUOTA_ACCT flag is set. The current code logic +seems wrong, Fix it and show proper options. + +Signed-off-by: Kaixu Xia +Reviewed-by: Darrick J. Wong +Signed-off-by: Darrick J. Wong +Signed-off-by: Amir Goldstein +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/xfs_super.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/fs/xfs/xfs_super.c ++++ b/fs/xfs/xfs_super.c +@@ -199,10 +199,12 @@ xfs_fs_show_options( + seq_printf(m, ",swidth=%d", + (int)XFS_FSB_TO_BB(mp, mp->m_swidth)); + +- if (mp->m_qflags & (XFS_UQUOTA_ACCT|XFS_UQUOTA_ENFD)) +- seq_puts(m, ",usrquota"); +- else if (mp->m_qflags & XFS_UQUOTA_ACCT) +- seq_puts(m, ",uqnoenforce"); ++ if (mp->m_qflags & XFS_UQUOTA_ACCT) { ++ if (mp->m_qflags & XFS_UQUOTA_ENFD) ++ seq_puts(m, ",usrquota"); ++ else ++ seq_puts(m, ",uqnoenforce"); ++ } + + if (mp->m_qflags & XFS_PQUOTA_ACCT) { + if (mp->m_qflags & XFS_PQUOTA_ENFD) diff --git a/queue-5.10/zsmalloc-fix-races-between-asynchronous-zspage-free-and-page-migration.patch b/queue-5.10/zsmalloc-fix-races-between-asynchronous-zspage-free-and-page-migration.patch new file mode 100644 index 00000000000..b97c795eac5 --- /dev/null +++ b/queue-5.10/zsmalloc-fix-races-between-asynchronous-zspage-free-and-page-migration.patch @@ -0,0 +1,86 @@ +From 2505a981114dcb715f8977b8433f7540854851d8 Mon Sep 17 00:00:00 2001 +From: Sultan Alsawaf +Date: Fri, 13 May 2022 15:11:26 -0700 +Subject: zsmalloc: fix races between asynchronous zspage free and page migration + +From: Sultan Alsawaf + +commit 2505a981114dcb715f8977b8433f7540854851d8 upstream. + +The asynchronous zspage free worker tries to lock a zspage's entire page +list without defending against page migration. Since pages which haven't +yet been locked can concurrently migrate off the zspage page list while +lock_zspage() churns away, lock_zspage() can suffer from a few different +lethal races. + +It can lock a page which no longer belongs to the zspage and unsafely +dereference page_private(), it can unsafely dereference a torn pointer to +the next page (since there's a data race), and it can observe a spurious +NULL pointer to the next page and thus not lock all of the zspage's pages +(since a single page migration will reconstruct the entire page list, and +create_page_chain() unconditionally zeroes out each list pointer in the +process). + +Fix the races by using migrate_read_lock() in lock_zspage() to synchronize +with page migration. + +Link: https://lkml.kernel.org/r/20220509024703.243847-1-sultan@kerneltoast.com +Fixes: 77ff465799c602 ("zsmalloc: zs_page_migrate: skip unnecessary loops but not return -EBUSY if zspage is not inuse") +Signed-off-by: Sultan Alsawaf +Acked-by: Minchan Kim +Cc: Nitin Gupta +Cc: Sergey Senozhatsky +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/zsmalloc.c | 37 +++++++++++++++++++++++++++++++++---- + 1 file changed, 33 insertions(+), 4 deletions(-) + +--- a/mm/zsmalloc.c ++++ b/mm/zsmalloc.c +@@ -1748,11 +1748,40 @@ static enum fullness_group putback_zspag + */ + static void lock_zspage(struct zspage *zspage) + { +- struct page *page = get_first_page(zspage); ++ struct page *curr_page, *page; + +- do { +- lock_page(page); +- } while ((page = get_next_page(page)) != NULL); ++ /* ++ * Pages we haven't locked yet can be migrated off the list while we're ++ * trying to lock them, so we need to be careful and only attempt to ++ * lock each page under migrate_read_lock(). Otherwise, the page we lock ++ * may no longer belong to the zspage. This means that we may wait for ++ * the wrong page to unlock, so we must take a reference to the page ++ * prior to waiting for it to unlock outside migrate_read_lock(). ++ */ ++ while (1) { ++ migrate_read_lock(zspage); ++ page = get_first_page(zspage); ++ if (trylock_page(page)) ++ break; ++ get_page(page); ++ migrate_read_unlock(zspage); ++ wait_on_page_locked(page); ++ put_page(page); ++ } ++ ++ curr_page = page; ++ while ((page = get_next_page(curr_page))) { ++ if (trylock_page(page)) { ++ curr_page = page; ++ } else { ++ get_page(page); ++ migrate_read_unlock(zspage); ++ wait_on_page_locked(page); ++ put_page(page); ++ migrate_read_lock(zspage); ++ } ++ } ++ migrate_read_unlock(zspage); + } + + static int zs_init_fs_context(struct fs_context *fc)