From: Greg Kroah-Hartman Date: Thu, 23 Nov 2023 12:21:59 +0000 (+0000) Subject: 4.19-stable patches X-Git-Tag: v4.14.331~88 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e1d1be9fc29f69f79c649ceb720688f9f3ff6812;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: dmaengine-stm32-mdma-correct-desc-prep-when-channel-running.patch jbd2-fix-potential-data-lost-in-recovering-journal-raced-with-synchronizing-fs-bdev.patch mcb-fix-error-handling-for-different-scenarios-when-parsing.patch quota-explicitly-forbid-quota-files-from-being-encrypted.patch s390-cmma-fix-handling-of-swapper_pg_dir-and-invalid_pg_dir.patch s390-cmma-fix-initial-kernel-address-space-page-table-walk.patch --- diff --git a/queue-4.19/dmaengine-stm32-mdma-correct-desc-prep-when-channel-running.patch b/queue-4.19/dmaengine-stm32-mdma-correct-desc-prep-when-channel-running.patch new file mode 100644 index 00000000000..251342ee4ff --- /dev/null +++ b/queue-4.19/dmaengine-stm32-mdma-correct-desc-prep-when-channel-running.patch @@ -0,0 +1,48 @@ +From 03f25d53b145bc2f7ccc82fc04e4482ed734f524 Mon Sep 17 00:00:00 2001 +From: Alain Volmat +Date: Mon, 9 Oct 2023 10:24:50 +0200 +Subject: dmaengine: stm32-mdma: correct desc prep when channel running + +From: Alain Volmat + +commit 03f25d53b145bc2f7ccc82fc04e4482ed734f524 upstream. + +In case of the prep descriptor while the channel is already running, the +CCR register value stored into the channel could already have its EN bit +set. This would lead to a bad transfer since, at start transfer time, +enabling the channel while other registers aren't yet properly set. +To avoid this, ensure to mask the CCR_EN bit when storing the ccr value +into the mdma channel structure. + +Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") +Signed-off-by: Alain Volmat +Signed-off-by: Amelie Delaunay +Cc: stable@vger.kernel.org +Tested-by: Alain Volmat +Link: https://lore.kernel.org/r/20231009082450.452877-1-amelie.delaunay@foss.st.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/stm32-mdma.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/dma/stm32-mdma.c ++++ b/drivers/dma/stm32-mdma.c +@@ -520,7 +520,7 @@ static int stm32_mdma_set_xfer_param(str + src_maxburst = chan->dma_config.src_maxburst; + dst_maxburst = chan->dma_config.dst_maxburst; + +- ccr = stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)); ++ ccr = stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & ~STM32_MDMA_CCR_EN; + ctcr = stm32_mdma_read(dmadev, STM32_MDMA_CTCR(chan->id)); + ctbr = stm32_mdma_read(dmadev, STM32_MDMA_CTBR(chan->id)); + +@@ -948,7 +948,7 @@ stm32_mdma_prep_dma_memcpy(struct dma_ch + if (!desc) + return NULL; + +- ccr = stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)); ++ ccr = stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & ~STM32_MDMA_CCR_EN; + ctcr = stm32_mdma_read(dmadev, STM32_MDMA_CTCR(chan->id)); + ctbr = stm32_mdma_read(dmadev, STM32_MDMA_CTBR(chan->id)); + cbndtr = stm32_mdma_read(dmadev, STM32_MDMA_CBNDTR(chan->id)); diff --git a/queue-4.19/jbd2-fix-potential-data-lost-in-recovering-journal-raced-with-synchronizing-fs-bdev.patch b/queue-4.19/jbd2-fix-potential-data-lost-in-recovering-journal-raced-with-synchronizing-fs-bdev.patch new file mode 100644 index 00000000000..99328522fe4 --- /dev/null +++ b/queue-4.19/jbd2-fix-potential-data-lost-in-recovering-journal-raced-with-synchronizing-fs-bdev.patch @@ -0,0 +1,94 @@ +From 61187fce8600e8ef90e601be84f9d0f3222c1206 Mon Sep 17 00:00:00 2001 +From: Zhihao Cheng +Date: Tue, 19 Sep 2023 09:25:25 +0800 +Subject: jbd2: fix potential data lost in recovering journal raced with synchronizing fs bdev + +From: Zhihao Cheng + +commit 61187fce8600e8ef90e601be84f9d0f3222c1206 upstream. + +JBD2 makes sure journal data is fallen on fs device by sync_blockdev(), +however, other process could intercept the EIO information from bdev's +mapping, which leads journal recovering successful even EIO occurs during +data written back to fs device. + +We found this problem in our product, iscsi + multipath is chosen for block +device of ext4. Unstable network may trigger kpartx to rescan partitions in +device mapper layer. Detailed process is shown as following: + + mount kpartx irq +jbd2_journal_recover + do_one_pass + memcpy(nbh->b_data, obh->b_data) // copy data to fs dev from journal + mark_buffer_dirty // mark bh dirty + vfs_read + generic_file_read_iter // dio + filemap_write_and_wait_range + __filemap_fdatawrite_range + do_writepages + block_write_full_folio + submit_bh_wbc + >> EIO occurs in disk << + end_buffer_async_write + mark_buffer_write_io_error + mapping_set_error + set_bit(AS_EIO, &mapping->flags) // set! + filemap_check_errors + test_and_clear_bit(AS_EIO, &mapping->flags) // clear! + err2 = sync_blockdev + filemap_write_and_wait + filemap_check_errors + test_and_clear_bit(AS_EIO, &mapping->flags) // false + err2 = 0 + +Filesystem is mounted successfully even data from journal is failed written +into disk, and ext4/ocfs2 could become corrupted. + +Fix it by comparing the wb_err state in fs block device before recovering +and after recovering. + +A reproducer can be found in the kernel bugzilla referenced below. + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217888 +Cc: stable@vger.kernel.org +Signed-off-by: Zhihao Cheng +Signed-off-by: Zhang Yi +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230919012525.1783108-1-chengzhihao1@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/jbd2/recovery.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/jbd2/recovery.c ++++ b/fs/jbd2/recovery.c +@@ -247,6 +247,8 @@ int jbd2_journal_recover(journal_t *jour + journal_superblock_t * sb; + + struct recovery_info info; ++ errseq_t wb_err; ++ struct address_space *mapping; + + memset(&info, 0, sizeof(info)); + sb = journal->j_superblock; +@@ -264,6 +266,9 @@ int jbd2_journal_recover(journal_t *jour + return 0; + } + ++ wb_err = 0; ++ mapping = journal->j_fs_dev->bd_inode->i_mapping; ++ errseq_check_and_advance(&mapping->wb_err, &wb_err); + err = do_one_pass(journal, &info, PASS_SCAN); + if (!err) + err = do_one_pass(journal, &info, PASS_REVOKE); +@@ -284,6 +289,9 @@ int jbd2_journal_recover(journal_t *jour + err2 = sync_blockdev(journal->j_fs_dev); + if (!err) + err = err2; ++ err2 = errseq_check_and_advance(&mapping->wb_err, &wb_err); ++ if (!err) ++ err = err2; + /* Make sure all replayed data is on permanent storage */ + if (journal->j_flags & JBD2_BARRIER) { + err2 = blkdev_issue_flush(journal->j_fs_dev, GFP_KERNEL, NULL); diff --git a/queue-4.19/mcb-fix-error-handling-for-different-scenarios-when-parsing.patch b/queue-4.19/mcb-fix-error-handling-for-different-scenarios-when-parsing.patch new file mode 100644 index 00000000000..43e60264f79 --- /dev/null +++ b/queue-4.19/mcb-fix-error-handling-for-different-scenarios-when-parsing.patch @@ -0,0 +1,49 @@ +From 63ba2d07b4be72b94216d20561f43e1150b25d98 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Sanju=C3=A1n=20Garc=C3=ADa=2C=20Jorge?= + +Date: Thu, 19 Oct 2023 14:15:34 +0000 +Subject: mcb: fix error handling for different scenarios when parsing + +From: Sanjuán García, Jorge + +commit 63ba2d07b4be72b94216d20561f43e1150b25d98 upstream. + +chameleon_parse_gdd() may fail for different reasons and end up +in the err tag. Make sure we at least always free the mcb_device +allocated with mcb_alloc_dev(). + +If mcb_device_register() fails, make sure to give up the reference +in the same place the device was added. + +Fixes: 728ac3389296 ("mcb: mcb-parse: fix error handing in chameleon_parse_gdd()") +Cc: stable +Reviewed-by: Jose Javier Rodriguez Barbarin +Signed-off-by: Jorge Sanjuan Garcia +Link: https://lore.kernel.org/r/20231019141434.57971-2-jorge.sanjuangarcia@duagon.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mcb/mcb-core.c | 1 + + drivers/mcb/mcb-parse.c | 2 +- + 2 files changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/mcb/mcb-core.c ++++ b/drivers/mcb/mcb-core.c +@@ -251,6 +251,7 @@ int mcb_device_register(struct mcb_bus * + return 0; + + out: ++ put_device(&dev->dev); + + return ret; + } +--- a/drivers/mcb/mcb-parse.c ++++ b/drivers/mcb/mcb-parse.c +@@ -105,7 +105,7 @@ static int chameleon_parse_gdd(struct mc + return 0; + + err: +- put_device(&mdev->dev); ++ mcb_free_dev(mdev); + + return ret; + } diff --git a/queue-4.19/quota-explicitly-forbid-quota-files-from-being-encrypted.patch b/queue-4.19/quota-explicitly-forbid-quota-files-from-being-encrypted.patch new file mode 100644 index 00000000000..145c385e8a9 --- /dev/null +++ b/queue-4.19/quota-explicitly-forbid-quota-files-from-being-encrypted.patch @@ -0,0 +1,64 @@ +From d3cc1b0be258191d6360c82ea158c2972f8d3991 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 4 Sep 2023 17:32:27 -0700 +Subject: quota: explicitly forbid quota files from being encrypted + +From: Eric Biggers + +commit d3cc1b0be258191d6360c82ea158c2972f8d3991 upstream. + +Since commit d7e7b9af104c ("fscrypt: stop using keyrings subsystem for +fscrypt_master_key"), xfstest generic/270 causes a WARNING when run on +f2fs with test_dummy_encryption in the mount options: + +$ kvm-xfstests -c f2fs/encrypt generic/270 +[...] +WARNING: CPU: 1 PID: 2453 at fs/crypto/keyring.c:240 fscrypt_destroy_keyring+0x1f5/0x260 + +The cause of the WARNING is that not all encrypted inodes have been +evicted before fscrypt_destroy_keyring() is called, which violates an +assumption. This happens because the test uses an external quota file, +which gets automatically encrypted due to test_dummy_encryption. + +Encryption of quota files has never really been supported. On ext4, +ext4_quota_read() does not decrypt the data, so encrypted quota files +are always considered invalid on ext4. On f2fs, f2fs_quota_read() uses +the pagecache, so trying to use an encrypted quota file gets farther, +resulting in the issue described above being possible. But this was +never intended to be possible, and there is no use case for it. + +Therefore, make the quota support layer explicitly reject using +IS_ENCRYPTED inodes when quotaon is attempted. + +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Jan Kara +Message-Id: <20230905003227.326998-1-ebiggers@kernel.org> +Signed-off-by: Greg Kroah-Hartman +--- + fs/quota/dquot.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/fs/quota/dquot.c ++++ b/fs/quota/dquot.c +@@ -2385,6 +2385,20 @@ static int vfs_setup_quota_inode(struct + if (sb_has_quota_loaded(sb, type)) + return -EBUSY; + ++ /* ++ * Quota files should never be encrypted. They should be thought of as ++ * filesystem metadata, not user data. New-style internal quota files ++ * cannot be encrypted by users anyway, but old-style external quota ++ * files could potentially be incorrectly created in an encrypted ++ * directory, hence this explicit check. Some reasons why encrypted ++ * quota files don't work include: (1) some filesystems that support ++ * encryption don't handle it in their quota_read and quota_write, and ++ * (2) cleaning up encrypted quota files at unmount would need special ++ * consideration, as quota files are cleaned up later than user files. ++ */ ++ if (IS_ENCRYPTED(inode)) ++ return -EINVAL; ++ + dqopt->files[type] = igrab(inode); + if (!dqopt->files[type]) + return -EIO; diff --git a/queue-4.19/s390-cmma-fix-handling-of-swapper_pg_dir-and-invalid_pg_dir.patch b/queue-4.19/s390-cmma-fix-handling-of-swapper_pg_dir-and-invalid_pg_dir.patch new file mode 100644 index 00000000000..0ab403e9821 --- /dev/null +++ b/queue-4.19/s390-cmma-fix-handling-of-swapper_pg_dir-and-invalid_pg_dir.patch @@ -0,0 +1,45 @@ +From 84bb41d5df48868055d159d9247b80927f1f70f9 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Tue, 24 Oct 2023 10:15:20 +0200 +Subject: s390/cmma: fix handling of swapper_pg_dir and invalid_pg_dir + +From: Heiko Carstens + +commit 84bb41d5df48868055d159d9247b80927f1f70f9 upstream. + +If the cmma no-dat feature is available the kernel page tables are walked +to identify and mark all pages which are used for address translation (all +region, segment, and page tables). In a subsequent loop all other pages are +marked as "no-dat" pages with the ESSA instruction. + +This information is visible to the hypervisor, so that the hypervisor can +optimize purging of guest TLB entries. All pages used for swapper_pg_dir +and invalid_pg_dir are incorrectly marked as no-dat, which in turn can +result in incorrect guest TLB flushes. + +Fix this by marking those pages correctly as being used for DAT. + +Cc: +Reviewed-by: Claudio Imbrenda +Signed-off-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/mm/page-states.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/arch/s390/mm/page-states.c ++++ b/arch/s390/mm/page-states.c +@@ -204,6 +204,12 @@ void __init cmma_init_nodat(void) + return; + /* Mark pages used in kernel page tables */ + mark_kernel_pgd(); ++ page = virt_to_page(&swapper_pg_dir); ++ for (i = 0; i < 4; i++) ++ set_bit(PG_arch_1, &page[i].flags); ++ page = virt_to_page(&invalid_pg_dir); ++ for (i = 0; i < 4; i++) ++ set_bit(PG_arch_1, &page[i].flags); + + /* Set all kernel pages not used for page tables to stable/no-dat */ + for_each_memblock(memory, reg) { diff --git a/queue-4.19/s390-cmma-fix-initial-kernel-address-space-page-table-walk.patch b/queue-4.19/s390-cmma-fix-initial-kernel-address-space-page-table-walk.patch new file mode 100644 index 00000000000..4881f314214 --- /dev/null +++ b/queue-4.19/s390-cmma-fix-initial-kernel-address-space-page-table-walk.patch @@ -0,0 +1,69 @@ +From 16ba44826a04834d3eeeda4b731c2ea3481062b7 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Tue, 17 Oct 2023 21:07:03 +0200 +Subject: s390/cmma: fix initial kernel address space page table walk + +From: Heiko Carstens + +commit 16ba44826a04834d3eeeda4b731c2ea3481062b7 upstream. + +If the cmma no-dat feature is available the kernel page tables are walked +to identify and mark all pages which are used for address translation (all +region, segment, and page tables). In a subsequent loop all other pages are +marked as "no-dat" pages with the ESSA instruction. + +This information is visible to the hypervisor, so that the hypervisor can +optimize purging of guest TLB entries. The initial loop however does not +cover the complete kernel address space. This can result in pages being +marked as not being used for dynamic address translation, even though they +are. In turn guest TLB entries incorrectly may not be purged. + +Fix this by adjusting the end address of the kernel address range being +walked. + +Cc: +Reviewed-by: Claudio Imbrenda +Reviewed-by: Alexander Gordeev +Signed-off-by: Heiko Carstens +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/mm/page-states.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/arch/s390/mm/page-states.c ++++ b/arch/s390/mm/page-states.c +@@ -167,15 +167,22 @@ static void mark_kernel_p4d(pgd_t *pgd, + + static void mark_kernel_pgd(void) + { +- unsigned long addr, next; ++ unsigned long addr, next, max_addr; + struct page *page; + pgd_t *pgd; + int i; + + addr = 0; ++ /* ++ * Figure out maximum virtual address accessible with the ++ * kernel ASCE. This is required to keep the page table walker ++ * from accessing non-existent entries. ++ */ ++ max_addr = (S390_lowcore.kernel_asce.val & _ASCE_TYPE_MASK) >> 2; ++ max_addr = 1UL << (max_addr * 11 + 31); + pgd = pgd_offset_k(addr); + do { +- next = pgd_addr_end(addr, MODULES_END); ++ next = pgd_addr_end(addr, max_addr); + if (pgd_none(*pgd)) + continue; + if (!pgd_folded(*pgd)) { +@@ -184,7 +191,7 @@ static void mark_kernel_pgd(void) + set_bit(PG_arch_1, &page[i].flags); + } + mark_kernel_p4d(pgd, addr, next); +- } while (pgd++, addr = next, addr != MODULES_END); ++ } while (pgd++, addr = next, addr != max_addr); + } + + void __init cmma_init_nodat(void) diff --git a/queue-4.19/series b/queue-4.19/series index e5cc1c8448f..ccb0bc8cbaf 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -62,3 +62,9 @@ clk-qcom-ipq8074-drop-the-clk_set_rate_parent-flag-from-pll-clocks.patch mmc-vub300-fix-an-error-code.patch pm-hibernate-use-__get_safe_page-rather-than-touching-the-list.patch pm-hibernate-clean-up-sync_read-handling-in-snapshot_write_next.patch +jbd2-fix-potential-data-lost-in-recovering-journal-raced-with-synchronizing-fs-bdev.patch +quota-explicitly-forbid-quota-files-from-being-encrypted.patch +mcb-fix-error-handling-for-different-scenarios-when-parsing.patch +dmaengine-stm32-mdma-correct-desc-prep-when-channel-running.patch +s390-cmma-fix-initial-kernel-address-space-page-table-walk.patch +s390-cmma-fix-handling-of-swapper_pg_dir-and-invalid_pg_dir.patch