From: Greg Kroah-Hartman Date: Thu, 15 Jul 2021 11:11:54 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v5.4.133~62 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=684b48cf2714457d75cc2ac9f1935fe7c2621b66;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: bdi-do-not-use-freezable-workqueue.patch fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch --- diff --git a/queue-4.14/bdi-do-not-use-freezable-workqueue.patch b/queue-4.14/bdi-do-not-use-freezable-workqueue.patch new file mode 100644 index 00000000000..55df22940b9 --- /dev/null +++ b/queue-4.14/bdi-do-not-use-freezable-workqueue.patch @@ -0,0 +1,83 @@ +From a2b90f11217790ec0964ba9c93a4abb369758c26 Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +Date: Fri, 4 Oct 2019 13:00:24 +0300 +Subject: bdi: Do not use freezable workqueue + +From: Mika Westerberg + +commit a2b90f11217790ec0964ba9c93a4abb369758c26 upstream. + +A removable block device, such as NVMe or SSD connected over Thunderbolt +can be hot-removed any time including when the system is suspended. When +device is hot-removed during suspend and the system gets resumed, kernel +first resumes devices and then thaws the userspace including freezable +workqueues. What happens in that case is that the NVMe driver notices +that the device is unplugged and removes it from the system. This ends +up calling bdi_unregister() for the gendisk which then schedules +wb_workfn() to be run one more time. + +However, since the bdi_wq is still frozen flush_delayed_work() call in +wb_shutdown() blocks forever halting system resume process. User sees +this as hang as nothing is happening anymore. + +Triggering sysrq-w reveals this: + + Workqueue: nvme-wq nvme_remove_dead_ctrl_work [nvme] + Call Trace: + ? __schedule+0x2c5/0x630 + ? wait_for_completion+0xa4/0x120 + schedule+0x3e/0xc0 + schedule_timeout+0x1c9/0x320 + ? resched_curr+0x1f/0xd0 + ? wait_for_completion+0xa4/0x120 + wait_for_completion+0xc3/0x120 + ? wake_up_q+0x60/0x60 + __flush_work+0x131/0x1e0 + ? flush_workqueue_prep_pwqs+0x130/0x130 + bdi_unregister+0xb9/0x130 + del_gendisk+0x2d2/0x2e0 + nvme_ns_remove+0xed/0x110 [nvme_core] + nvme_remove_namespaces+0x96/0xd0 [nvme_core] + nvme_remove+0x5b/0x160 [nvme] + pci_device_remove+0x36/0x90 + device_release_driver_internal+0xdf/0x1c0 + nvme_remove_dead_ctrl_work+0x14/0x30 [nvme] + process_one_work+0x1c2/0x3f0 + worker_thread+0x48/0x3e0 + kthread+0x100/0x140 + ? current_work+0x30/0x30 + ? kthread_park+0x80/0x80 + ret_from_fork+0x35/0x40 + +This is not limited to NVMes so exactly same issue can be reproduced by +hot-removing SSD (over Thunderbolt) while the system is suspended. + +Prevent this from happening by removing WQ_FREEZABLE from bdi_wq. + +Reported-by: AceLan Kao +Link: https://marc.info/?l=linux-kernel&m=138695698516487 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=204385 +Link: https://lore.kernel.org/lkml/20191002122136.GD2819@lahna.fi.intel.com/#t +Acked-by: Rafael J. Wysocki +Signed-off-by: Mika Westerberg +Signed-off-by: Jens Axboe +Cc: Macpaul Lin +Signed-off-by: Greg Kroah-Hartman + +--- + mm/backing-dev.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/backing-dev.c ++++ b/mm/backing-dev.c +@@ -247,8 +247,8 @@ static int __init default_bdi_init(void) + { + int err; + +- bdi_wq = alloc_workqueue("writeback", WQ_MEM_RECLAIM | WQ_FREEZABLE | +- WQ_UNBOUND | WQ_SYSFS, 0); ++ bdi_wq = alloc_workqueue("writeback", WQ_MEM_RECLAIM | WQ_UNBOUND | ++ WQ_SYSFS, 0); + if (!bdi_wq) + return -ENOMEM; + diff --git a/queue-4.14/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch b/queue-4.14/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch new file mode 100644 index 00000000000..dad5a47e22d --- /dev/null +++ b/queue-4.14/fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch @@ -0,0 +1,59 @@ +From 77f30bfcfcf484da7208affd6a9e63406420bf91 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 27 May 2021 16:52:36 -0700 +Subject: fscrypt: don't ignore minor_hash when hash is 0 + +From: Eric Biggers + +commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream. + +When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the +minor_hash to 0 if the (major) hash is 0. + +This doesn't make sense because 0 is a valid hash code, so we shouldn't +ignore the filesystem-provided minor_hash in that case. Fix this by +removing the special case for 'hash == 0'. + +This is an old bug that appears to have originated when the encryption +code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and +f2fs code passed the hash by pointer instead of by value. So +'if (hash)' actually made sense then, as it was checking whether a +pointer was NULL. But now the hashes are passed by value, and +filesystems just pass 0 for any hashes they don't have. There is no +need to handle this any differently from the hashes actually being 0. + +It is difficult to reproduce this bug, as it only made a difference in +the case where a filename's 32-bit major hash happened to be 0. +However, it probably had the largest chance of causing problems on +ubifs, since ubifs uses minor_hash to do lookups of no-key names, in +addition to using it as a readdir cookie. ext4 only uses minor_hash as +a readdir cookie, and f2fs doesn't use minor_hash at all. + +Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto") +Cc: # v4.6+ +Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman + +--- + fs/crypto/fname.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/fs/crypto/fname.c ++++ b/fs/crypto/fname.c +@@ -304,13 +304,8 @@ int fscrypt_fname_disk_to_usr(struct ino + oname->name); + return 0; + } +- if (hash) { +- digested_name.hash = hash; +- digested_name.minor_hash = minor_hash; +- } else { +- digested_name.hash = 0; +- digested_name.minor_hash = 0; +- } ++ digested_name.hash = hash; ++ digested_name.minor_hash = minor_hash; + memcpy(digested_name.digest, + FSCRYPT_FNAME_DIGEST(iname->name, iname->len), + FSCRYPT_FNAME_DIGEST_SIZE); diff --git a/queue-4.14/series b/queue-4.14/series index d360c5e789d..3e8eedb3131 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -200,3 +200,5 @@ bluetooth-shutdown-controller-after-workqueues-are-f.patch bluetooth-btusb-fix-bt-fiwmare-downloading-failure-i.patch sctp-validate-from_addr_param-return.patch sctp-add-size-validation-when-walking-chunks.patch +fscrypt-don-t-ignore-minor_hash-when-hash-is-0.patch +bdi-do-not-use-freezable-workqueue.patch