From: Greg Kroah-Hartman Date: Mon, 27 Jun 2022 08:51:06 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v5.4.202~30 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f3b3f77c84f8b735bcc1a73392794bffc955b7fb;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: btrfs-don-t-set-lock_owner-when-locking-extent-buffer-for-reading.patch btrfs-fix-deadlock-with-fsync-fiemap-transaction-commit.patch dt-bindings-usb-ehci-increase-the-number-of-phys.patch dt-bindings-usb-ohci-increase-the-number-of-phys.patch f2fs-attach-inline_data-after-setting-compression.patch iio-humidity-hts221-rearrange-iio-trigger-get-and-register.patch usb-chipidea-udc-check-request-status-before-setting-device-address.patch --- diff --git a/queue-5.15/btrfs-don-t-set-lock_owner-when-locking-extent-buffer-for-reading.patch b/queue-5.15/btrfs-don-t-set-lock_owner-when-locking-extent-buffer-for-reading.patch new file mode 100644 index 00000000000..ce31d01c657 --- /dev/null +++ b/queue-5.15/btrfs-don-t-set-lock_owner-when-locking-extent-buffer-for-reading.patch @@ -0,0 +1,62 @@ +From 97e86631bccddfbbe0c13f9a9605cdef11d31296 Mon Sep 17 00:00:00 2001 +From: Zygo Blaxell +Date: Wed, 8 Jun 2022 22:39:36 -0400 +Subject: btrfs: don't set lock_owner when locking extent buffer for reading + +From: Zygo Blaxell + +commit 97e86631bccddfbbe0c13f9a9605cdef11d31296 upstream. + +In 196d59ab9ccc "btrfs: switch extent buffer tree lock to rw_semaphore" +the functions for tree read locking were rewritten, and in the process +the read lock functions started setting eb->lock_owner = current->pid. +Previously lock_owner was only set in tree write lock functions. + +Read locks are shared, so they don't have exclusive ownership of the +underlying object, so setting lock_owner to any single value for a +read lock makes no sense. It's mostly harmless because write locks +and read locks are mutually exclusive, and none of the existing code +in btrfs (btrfs_init_new_buffer and print_eb_refs_lock) cares what +nonsense is written in lock_owner when no writer is holding the lock. + +KCSAN does care, and will complain about the data race incessantly. +Remove the assignments in the read lock functions because they're +useless noise. + +Fixes: 196d59ab9ccc ("btrfs: switch extent buffer tree lock to rw_semaphore") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Nikolay Borisov +Reviewed-by: Filipe Manana +Signed-off-by: Zygo Blaxell +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/locking.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/fs/btrfs/locking.c ++++ b/fs/btrfs/locking.c +@@ -45,7 +45,6 @@ void __btrfs_tree_read_lock(struct exten + start_ns = ktime_get_ns(); + + down_read_nested(&eb->lock, nest); +- eb->lock_owner = current->pid; + trace_btrfs_tree_read_lock(eb, start_ns); + } + +@@ -62,7 +61,6 @@ void btrfs_tree_read_lock(struct extent_ + int btrfs_try_tree_read_lock(struct extent_buffer *eb) + { + if (down_read_trylock(&eb->lock)) { +- eb->lock_owner = current->pid; + trace_btrfs_try_tree_read_lock(eb); + return 1; + } +@@ -90,7 +88,6 @@ int btrfs_try_tree_write_lock(struct ext + void btrfs_tree_read_unlock(struct extent_buffer *eb) + { + trace_btrfs_tree_read_unlock(eb); +- eb->lock_owner = 0; + up_read(&eb->lock); + } + diff --git a/queue-5.15/btrfs-fix-deadlock-with-fsync-fiemap-transaction-commit.patch b/queue-5.15/btrfs-fix-deadlock-with-fsync-fiemap-transaction-commit.patch new file mode 100644 index 00000000000..55fd9ae540d --- /dev/null +++ b/queue-5.15/btrfs-fix-deadlock-with-fsync-fiemap-transaction-commit.patch @@ -0,0 +1,133 @@ +From bf7ba8ee759b7b7a34787ddd8dc3f190a3d7fa24 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Mon, 13 Jun 2022 15:09:49 -0400 +Subject: btrfs: fix deadlock with fsync+fiemap+transaction commit + +From: Josef Bacik + +commit bf7ba8ee759b7b7a34787ddd8dc3f190a3d7fa24 upstream. + +We are hitting the following deadlock in production occasionally + +Task 1 Task 2 Task 3 Task 4 Task 5 + fsync(A) + start trans + start commit + falloc(A) + lock 5m-10m + start trans + wait for commit +fiemap(A) + lock 0-10m + wait for 5m-10m + (have 0-5m locked) + + have btrfs_need_log_full_commit + !full_sync + wait_ordered_extents + finish_ordered_io(A) + lock 0-5m + DEADLOCK + +We have an existing dependency of file extent lock -> transaction. +However in fsync if we tried to do the fast logging, but then had to +fall back to committing the transaction, we will be forced to call +btrfs_wait_ordered_range() to make sure all of our extents are updated. + +This creates a dependency of transaction -> file extent lock, because +btrfs_finish_ordered_io() will need to take the file extent lock in +order to run the ordered extents. + +Fix this by stopping the transaction if we have to do the full commit +and we attempted to do the fast logging. Then attach to the transaction +and commit it if we need to. + +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Filipe Manana +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/file.c | 67 +++++++++++++++++++++++++++++++++++++++++++------------- + 1 file changed, 52 insertions(+), 15 deletions(-) + +--- a/fs/btrfs/file.c ++++ b/fs/btrfs/file.c +@@ -2337,25 +2337,62 @@ int btrfs_sync_file(struct file *file, l + */ + btrfs_inode_unlock(inode, BTRFS_ILOCK_MMAP); + +- if (ret != BTRFS_NO_LOG_SYNC) { ++ if (ret == BTRFS_NO_LOG_SYNC) { ++ ret = btrfs_end_transaction(trans); ++ goto out; ++ } ++ ++ /* We successfully logged the inode, attempt to sync the log. */ ++ if (!ret) { ++ ret = btrfs_sync_log(trans, root, &ctx); + if (!ret) { +- ret = btrfs_sync_log(trans, root, &ctx); +- if (!ret) { +- ret = btrfs_end_transaction(trans); +- goto out; +- } ++ ret = btrfs_end_transaction(trans); ++ goto out; + } +- if (!full_sync) { +- ret = btrfs_wait_ordered_range(inode, start, len); +- if (ret) { +- btrfs_end_transaction(trans); +- goto out; +- } +- } +- ret = btrfs_commit_transaction(trans); +- } else { ++ } ++ ++ /* ++ * At this point we need to commit the transaction because we had ++ * btrfs_need_log_full_commit() or some other error. ++ * ++ * If we didn't do a full sync we have to stop the trans handle, wait on ++ * the ordered extents, start it again and commit the transaction. If ++ * we attempt to wait on the ordered extents here we could deadlock with ++ * something like fallocate() that is holding the extent lock trying to ++ * start a transaction while some other thread is trying to commit the ++ * transaction while we (fsync) are currently holding the transaction ++ * open. ++ */ ++ if (!full_sync) { + ret = btrfs_end_transaction(trans); ++ if (ret) ++ goto out; ++ ret = btrfs_wait_ordered_range(inode, start, len); ++ if (ret) ++ goto out; ++ ++ /* ++ * This is safe to use here because we're only interested in ++ * making sure the transaction that had the ordered extents is ++ * committed. We aren't waiting on anything past this point, ++ * we're purely getting the transaction and committing it. ++ */ ++ trans = btrfs_attach_transaction_barrier(root); ++ if (IS_ERR(trans)) { ++ ret = PTR_ERR(trans); ++ ++ /* ++ * We committed the transaction and there's no currently ++ * running transaction, this means everything we care ++ * about made it to disk and we are done. ++ */ ++ if (ret == -ENOENT) ++ ret = 0; ++ goto out; ++ } + } ++ ++ ret = btrfs_commit_transaction(trans); + out: + ASSERT(list_empty(&ctx.list)); + err = file_check_and_advance_wb_err(file); diff --git a/queue-5.15/dt-bindings-usb-ehci-increase-the-number-of-phys.patch b/queue-5.15/dt-bindings-usb-ehci-increase-the-number-of-phys.patch new file mode 100644 index 00000000000..26bb0a4bce1 --- /dev/null +++ b/queue-5.15/dt-bindings-usb-ehci-increase-the-number-of-phys.patch @@ -0,0 +1,40 @@ +From 9faa1c8f92f33daad9db96944139de225cefa199 Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Wed, 15 Jun 2022 15:53:09 +0200 +Subject: dt-bindings: usb: ehci: Increase the number of PHYs + +From: Geert Uytterhoeven + +commit 9faa1c8f92f33daad9db96944139de225cefa199 upstream. + +"make dtbs_check": + + arch/arm/boot/dts/r8a77470-iwg23s-sbc.dtb: usb@ee080100: phys: [[17, 0], [31]] is too long + From schema: Documentation/devicetree/bindings/usb/generic-ehci.yaml + arch/arm/boot/dts/r8a77470-iwg23s-sbc.dtb: usb@ee0c0100: phys: [[17, 1], [33], [21, 0]] is too long + From schema: Documentation/devicetree/bindings/usb/generic-ehci.yaml + +Some USB EHCI controllers (e.g. on the Renesas RZ/G1C SoC) have multiple +PHYs. Increase the maximum number of PHYs to 3, which is sufficient for +now. + +Fixes: 0499220d6dadafa5 ("dt-bindings: Add missing array size constraints") +Signed-off-by: Geert Uytterhoeven +Link: https://lore.kernel.org/r/c5d19e2f9714f43effd90208798fc1936098078f.1655301043.git.geert+renesas@glider.be +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/devicetree/bindings/usb/generic-ehci.yaml | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml ++++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml +@@ -135,7 +135,8 @@ properties: + Phandle of a companion. + + phys: +- maxItems: 1 ++ minItems: 1 ++ maxItems: 3 + + phy-names: + const: usb diff --git a/queue-5.15/dt-bindings-usb-ohci-increase-the-number-of-phys.patch b/queue-5.15/dt-bindings-usb-ohci-increase-the-number-of-phys.patch new file mode 100644 index 00000000000..ab2b7b44ae6 --- /dev/null +++ b/queue-5.15/dt-bindings-usb-ohci-increase-the-number-of-phys.patch @@ -0,0 +1,40 @@ +From 0f074c1c95ea496dc91279b6c4b9845a337517fa Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Wed, 15 Jun 2022 15:54:02 +0200 +Subject: dt-bindings: usb: ohci: Increase the number of PHYs + +From: Geert Uytterhoeven + +commit 0f074c1c95ea496dc91279b6c4b9845a337517fa upstream. + +"make dtbs_check": + + arch/arm/boot/dts/r8a77470-iwg23s-sbc.dtb: usb@ee080000: phys: [[17, 0], [31]] is too long + From schema: Documentation/devicetree/bindings/usb/generic-ohci.yaml + arch/arm/boot/dts/r8a77470-iwg23s-sbc.dtb: usb@ee0c0000: phys: [[17, 1], [33], [21, 0]] is too long + From schema: Documentation/devicetree/bindings/usb/generic-ohci.yaml + +Some USB OHCI controllers (e.g. on the Renesas RZ/G1C SoC) have multiple +PHYs. Increase the maximum number of PHYs to 3, which is sufficient for +now. + +Fixes: 0499220d6dadafa5 ("dt-bindings: Add missing array size constraints") +Signed-off-by: Geert Uytterhoeven +Link: https://lore.kernel.org/r/0112f9c8881513cb33bf7b66bc743dd08b35a2f5.1655301203.git.geert+renesas@glider.be +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/devicetree/bindings/usb/generic-ohci.yaml | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml ++++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml +@@ -102,7 +102,8 @@ properties: + Overrides the detected port count + + phys: +- maxItems: 1 ++ minItems: 1 ++ maxItems: 3 + + phy-names: + const: usb diff --git a/queue-5.15/f2fs-attach-inline_data-after-setting-compression.patch b/queue-5.15/f2fs-attach-inline_data-after-setting-compression.patch new file mode 100644 index 00000000000..22dfdac2903 --- /dev/null +++ b/queue-5.15/f2fs-attach-inline_data-after-setting-compression.patch @@ -0,0 +1,68 @@ +From 4cde00d50707c2ef6647b9b96b2cb40b6eb24397 Mon Sep 17 00:00:00 2001 +From: Jaegeuk Kim +Date: Tue, 31 May 2022 18:27:09 -0700 +Subject: f2fs: attach inline_data after setting compression + +From: Jaegeuk Kim + +commit 4cde00d50707c2ef6647b9b96b2cb40b6eb24397 upstream. + +This fixes the below corruption. + +[345393.335389] F2FS-fs (vdb): sanity_check_inode: inode (ino=6d0, mode=33206) should not have inline_data, run fsck to fix + +Cc: +Fixes: 677a82b44ebf ("f2fs: fix to do sanity check for inline inode") +Signed-off-by: Jaegeuk Kim +Signed-off-by: Greg Kroah-Hartman +--- + fs/f2fs/namei.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +--- a/fs/f2fs/namei.c ++++ b/fs/f2fs/namei.c +@@ -91,8 +91,6 @@ static struct inode *f2fs_new_inode(stru + if (test_opt(sbi, INLINE_XATTR)) + set_inode_flag(inode, FI_INLINE_XATTR); + +- if (test_opt(sbi, INLINE_DATA) && f2fs_may_inline_data(inode)) +- set_inode_flag(inode, FI_INLINE_DATA); + if (f2fs_may_inline_dentry(inode)) + set_inode_flag(inode, FI_INLINE_DENTRY); + +@@ -109,10 +107,6 @@ static struct inode *f2fs_new_inode(stru + + f2fs_init_extent_tree(inode, NULL); + +- stat_inc_inline_xattr(inode); +- stat_inc_inline_inode(inode); +- stat_inc_inline_dir(inode); +- + F2FS_I(inode)->i_flags = + f2fs_mask_flags(mode, F2FS_I(dir)->i_flags & F2FS_FL_INHERITED); + +@@ -129,6 +123,14 @@ static struct inode *f2fs_new_inode(stru + set_compress_context(inode); + } + ++ /* Should enable inline_data after compression set */ ++ if (test_opt(sbi, INLINE_DATA) && f2fs_may_inline_data(inode)) ++ set_inode_flag(inode, FI_INLINE_DATA); ++ ++ stat_inc_inline_xattr(inode); ++ stat_inc_inline_inode(inode); ++ stat_inc_inline_dir(inode); ++ + f2fs_set_inode_flags(inode); + + trace_f2fs_new_inode(inode, 0); +@@ -327,6 +329,9 @@ static void set_compress_inode(struct f2 + if (!is_extension_exist(name, ext[i], false)) + continue; + ++ /* Do not use inline_data with compression */ ++ stat_dec_inline_inode(inode); ++ clear_inode_flag(inode, FI_INLINE_DATA); + set_compress_context(inode); + return; + } diff --git a/queue-5.15/iio-humidity-hts221-rearrange-iio-trigger-get-and-register.patch b/queue-5.15/iio-humidity-hts221-rearrange-iio-trigger-get-and-register.patch new file mode 100644 index 00000000000..ad9a0d1e1f1 --- /dev/null +++ b/queue-5.15/iio-humidity-hts221-rearrange-iio-trigger-get-and-register.patch @@ -0,0 +1,45 @@ +From 10b9c2c33ac706face458feab8965f11743c98c0 Mon Sep 17 00:00:00 2001 +From: Dmitry Rokosov +Date: Tue, 24 May 2022 18:14:46 +0000 +Subject: iio:humidity:hts221: rearrange iio trigger get and register + +From: Dmitry Rokosov + +commit 10b9c2c33ac706face458feab8965f11743c98c0 upstream. + +IIO trigger interface function iio_trigger_get() should be called after +iio_trigger_register() (or its devm analogue) strictly, because of +iio_trigger_get() acquires module refcnt based on the trigger->owner +pointer, which is initialized inside iio_trigger_register() to +THIS_MODULE. +If this call order is wrong, the next iio_trigger_put() (from sysfs +callback or "delete module" path) will dereference "default" module +refcnt, which is incorrect behaviour. + +Fixes: e4a70e3e7d84 ("iio: humidity: add support to hts221 rh/temp combo device") +Signed-off-by: Dmitry Rokosov +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20220524181150.9240-6-ddrokosov@sberdevices.ru +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/humidity/hts221_buffer.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/iio/humidity/hts221_buffer.c ++++ b/drivers/iio/humidity/hts221_buffer.c +@@ -135,9 +135,12 @@ int hts221_allocate_trigger(struct iio_d + + iio_trigger_set_drvdata(hw->trig, iio_dev); + hw->trig->ops = &hts221_trigger_ops; ++ ++ err = devm_iio_trigger_register(hw->dev, hw->trig); ++ + iio_dev->trig = iio_trigger_get(hw->trig); + +- return devm_iio_trigger_register(hw->dev, hw->trig); ++ return err; + } + + static int hts221_buffer_preenable(struct iio_dev *iio_dev) diff --git a/queue-5.15/series b/queue-5.15/series index 679b9324387..710a0ec8d30 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -86,3 +86,10 @@ xhci-pci-allow-host-runtime-pm-as-default-for-intel-raptor-lake-xhci.patch xhci-pci-allow-host-runtime-pm-as-default-for-intel-meteor-lake-xhci.patch usb-gadget-fix-non-unique-driver-names-in-raw-gadget-driver.patch usb-gadget-fix-double-free-bug-in-raw_gadget-driver.patch +usb-chipidea-udc-check-request-status-before-setting-device-address.patch +dt-bindings-usb-ohci-increase-the-number-of-phys.patch +dt-bindings-usb-ehci-increase-the-number-of-phys.patch +btrfs-don-t-set-lock_owner-when-locking-extent-buffer-for-reading.patch +btrfs-fix-deadlock-with-fsync-fiemap-transaction-commit.patch +f2fs-attach-inline_data-after-setting-compression.patch +iio-humidity-hts221-rearrange-iio-trigger-get-and-register.patch diff --git a/queue-5.15/usb-chipidea-udc-check-request-status-before-setting-device-address.patch b/queue-5.15/usb-chipidea-udc-check-request-status-before-setting-device-address.patch new file mode 100644 index 00000000000..3392ae8f072 --- /dev/null +++ b/queue-5.15/usb-chipidea-udc-check-request-status-before-setting-device-address.patch @@ -0,0 +1,34 @@ +From b24346a240b36cfc4df194d145463874985aa29b Mon Sep 17 00:00:00 2001 +From: Xu Yang +Date: Thu, 23 Jun 2022 11:02:42 +0800 +Subject: usb: chipidea: udc: check request status before setting device address + +From: Xu Yang + +commit b24346a240b36cfc4df194d145463874985aa29b upstream. + +The complete() function may be called even though request is not +completed. In this case, it's necessary to check request status so +as not to set device address wrongly. + +Fixes: 10775eb17bee ("usb: chipidea: udc: update gadget states according to ch9") +cc: +Signed-off-by: Xu Yang +Link: https://lore.kernel.org/r/20220623030242.41796-1-xu.yang_2@nxp.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/chipidea/udc.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/chipidea/udc.c ++++ b/drivers/usb/chipidea/udc.c +@@ -1040,6 +1040,9 @@ isr_setup_status_complete(struct usb_ep + struct ci_hdrc *ci = req->context; + unsigned long flags; + ++ if (req->status < 0) ++ return; ++ + if (ci->setaddr) { + hw_usb_set_address(ci, ci->address); + ci->setaddr = false;