--- /dev/null
+From a2b90f11217790ec0964ba9c93a4abb369758c26 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Fri, 4 Oct 2019 13:00:24 +0300
+Subject: bdi: Do not use freezable workqueue
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+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 <acelan.kao@canonical.com>
+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 <rafael.j.wysocki@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Cc: Macpaul Lin <macpaul.lin@mediatek.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 77f30bfcfcf484da7208affd6a9e63406420bf91 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 27 May 2021 16:52:36 -0700
+Subject: fscrypt: don't ignore minor_hash when hash is 0
+
+From: Eric Biggers <ebiggers@google.com>
+
+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: <stable@vger.kernel.org> # v4.6+
+Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
