From: Greg Kroah-Hartman Date: Mon, 22 Mar 2021 09:57:46 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.4.263~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=16b859d7248893962db493e082195529e2d4933a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: efi-use-32-bit-alignment-for-efi_guid_t-literals.patch efivars-respect-efi_unsupported-return-from-firmware.patch ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch ext4-fix-error-handling-in-ext4_end_enable_verity.patch ext4-fix-potential-error-in-ext4_do_update_inode.patch ext4-fix-rename-whiteout-with-fast-commit.patch ext4-stop-inode-update-before-return.patch firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch genirq-disable-interrupts-for-force-threaded-handlers.patch maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch static_call-fix-static_call_update-sanity-check.patch x86-apic-of-fix-cpu-devicetree-node-lookups.patch --- diff --git a/queue-5.10/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch b/queue-5.10/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch new file mode 100644 index 00000000000..0ac2eef6829 --- /dev/null +++ b/queue-5.10/efi-use-32-bit-alignment-for-efi_guid_t-literals.patch @@ -0,0 +1,66 @@ +From fb98cc0b3af2ba4d87301dff2b381b12eee35d7d Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Wed, 10 Mar 2021 08:33:19 +0100 +Subject: efi: use 32-bit alignment for efi_guid_t literals + +From: Ard Biesheuvel + +commit fb98cc0b3af2ba4d87301dff2b381b12eee35d7d upstream. + +Commit 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") updated +the type definition of efi_guid_t to ensure that it always appears +sufficiently aligned (the UEFI spec is ambiguous about this, but given +the fact that its EFI_GUID type is defined in terms of a struct carrying +a uint32_t, the natural alignment is definitely >= 32 bits). + +However, we missed the EFI_GUID() macro which is used to instantiate +efi_guid_t literals: that macro is still based on the guid_t type, +which does not have a minimum alignment at all. This results in warnings +such as + + In file included from drivers/firmware/efi/mokvar-table.c:35: + include/linux/efi.h:1093:34: warning: passing 1-byte aligned argument to + 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer + access [-Walign-mismatch] + status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, + ^ + include/linux/efi.h:1101:24: warning: passing 1-byte aligned argument to + 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer + access [-Walign-mismatch] + get_var(L"SetupMode", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &setupmode); + +The distinction only matters on CPUs that do not support misaligned loads +fully, but 32-bit ARM's load-multiple instructions fall into that category, +and these are likely to be emitted by the compiler that built the firmware +for loading word-aligned 128-bit GUIDs from memory + +So re-implement the initializer in terms of our own efi_guid_t type, so that +the alignment becomes a property of the literal's type. + +Fixes: 494c704f9af0 ("efi: Use 32-bit alignment for efi_guid_t") +Reported-by: Nathan Chancellor +Reviewed-by: Nick Desaulniers +Reviewed-by: Nathan Chancellor +Tested-by: Nathan Chancellor +Link: https://github.com/ClangBuiltLinux/linux/issues/1327 +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/efi.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/include/linux/efi.h ++++ b/include/linux/efi.h +@@ -72,8 +72,10 @@ typedef void *efi_handle_t; + */ + typedef guid_t efi_guid_t __aligned(__alignof__(u32)); + +-#define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \ +- GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) ++#define EFI_GUID(a, b, c, d...) (efi_guid_t){ { \ ++ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \ ++ (b) & 0xff, ((b) >> 8) & 0xff, \ ++ (c) & 0xff, ((c) >> 8) & 0xff, d } } + + /* + * Generic EFI table header diff --git a/queue-5.10/efivars-respect-efi_unsupported-return-from-firmware.patch b/queue-5.10/efivars-respect-efi_unsupported-return-from-firmware.patch new file mode 100644 index 00000000000..411e5b165ff --- /dev/null +++ b/queue-5.10/efivars-respect-efi_unsupported-return-from-firmware.patch @@ -0,0 +1,40 @@ +From 483028edacab374060d93955382b4865a9e07cba Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Wed, 17 Mar 2021 14:36:06 +0800 +Subject: efivars: respect EFI_UNSUPPORTED return from firmware + +From: Shawn Guo + +commit 483028edacab374060d93955382b4865a9e07cba upstream. + +As per UEFI spec 2.8B section 8.2, EFI_UNSUPPORTED may be returned by +EFI variable runtime services if no variable storage is supported by +firmware. In this case, there is no point for kernel to continue +efivars initialization. That said, efivar_init() should fail by +returning an error code, so that efivarfs will not be mounted on +/sys/firmware/efi/efivars at all. Otherwise, user space like efibootmgr +will be confused by the EFIVARFS_MAGIC seen there, while EFI variable +calls cannot be made successfully. + +Cc: # v5.10+ +Signed-off-by: Shawn Guo +Acked-by: Ard Biesheuvel +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/vars.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/firmware/efi/vars.c ++++ b/drivers/firmware/efi/vars.c +@@ -485,6 +485,10 @@ int efivar_init(int (*func)(efi_char16_t + } + + break; ++ case EFI_UNSUPPORTED: ++ err = -EOPNOTSUPP; ++ status = EFI_NOT_FOUND; ++ break; + case EFI_NOT_FOUND: + break; + default: diff --git a/queue-5.10/ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch b/queue-5.10/ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch new file mode 100644 index 00000000000..0eeeb435ebb --- /dev/null +++ b/queue-5.10/ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch @@ -0,0 +1,57 @@ +From 6b22489911b726eebbf169caee52fea52013fbdd Mon Sep 17 00:00:00 2001 +From: "zhangyi (F)" +Date: Fri, 5 Mar 2021 20:05:08 +0800 +Subject: ext4: do not try to set xattr into ea_inode if value is empty + +From: zhangyi (F) + +commit 6b22489911b726eebbf169caee52fea52013fbdd upstream. + +Syzbot report a warning that ext4 may create an empty ea_inode if set +an empty extent attribute to a file on the file system which is no free +blocks left. + + WARNING: CPU: 6 PID: 10667 at fs/ext4/xattr.c:1640 ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640 + ... + Call trace: + ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640 + ext4_xattr_block_set+0x1d0/0x1b1c fs/ext4/xattr.c:1942 + ext4_xattr_set_handle+0x8a0/0xf1c fs/ext4/xattr.c:2390 + ext4_xattr_set+0x120/0x1f0 fs/ext4/xattr.c:2491 + ext4_xattr_trusted_set+0x48/0x5c fs/ext4/xattr_trusted.c:37 + __vfs_setxattr+0x208/0x23c fs/xattr.c:177 + ... + +Now, ext4 try to store extent attribute into an external inode if +ext4_xattr_block_set() return -ENOSPC, but for the case of store an +empty extent attribute, store the extent entry into the extent +attribute block is enough. A simple reproduce below. + + fallocate test.img -l 1M + mkfs.ext4 -F -b 2048 -O ea_inode test.img + mount test.img /mnt + dd if=/dev/zero of=/mnt/foo bs=2048 count=500 + setfattr -n "user.test" /mnt/foo + +Reported-by: syzbot+98b881fdd8ebf45ab4ae@syzkaller.appspotmail.com +Fixes: 9c6e7853c531 ("ext4: reserve space for xattr entries/names") +Cc: stable@kernel.org +Signed-off-by: zhangyi (F) +Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/xattr.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/xattr.c ++++ b/fs/ext4/xattr.c +@@ -2398,7 +2398,7 @@ retry_inode: + * external inode if possible. + */ + if (ext4_has_feature_ea_inode(inode->i_sb) && +- !i.in_inode) { ++ i.value_len && !i.in_inode) { + i.in_inode = 1; + goto retry_inode; + } diff --git a/queue-5.10/ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch b/queue-5.10/ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch new file mode 100644 index 00000000000..c466dd88a9f --- /dev/null +++ b/queue-5.10/ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch @@ -0,0 +1,73 @@ +From b7ff91fd030dc9d72ed91b1aab36e445a003af4f Mon Sep 17 00:00:00 2001 +From: "zhangyi (F)" +Date: Wed, 3 Mar 2021 21:17:02 +0800 +Subject: ext4: find old entry again if failed to rename whiteout + +From: zhangyi (F) + +commit b7ff91fd030dc9d72ed91b1aab36e445a003af4f upstream. + +If we failed to add new entry on rename whiteout, we cannot reset the +old->de entry directly, because the old->de could have moved from under +us during make indexed dir. So find the old entry again before reset is +needed, otherwise it may corrupt the filesystem as below. + + /dev/sda: Entry '00000001' in ??? (12) has deleted/unused inode 15. CLEARED. + /dev/sda: Unattached inode 75 + /dev/sda: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. + +Fixes: 6b4b8e6b4ad ("ext4: fix bug for rename with RENAME_WHITEOUT") +Cc: stable@vger.kernel.org +Signed-off-by: zhangyi (F) +Link: https://lore.kernel.org/r/20210303131703.330415-1-yi.zhang@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/namei.c | 29 +++++++++++++++++++++++++++-- + 1 file changed, 27 insertions(+), 2 deletions(-) + +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -3604,6 +3604,31 @@ static int ext4_setent(handle_t *handle, + return retval; + } + ++static void ext4_resetent(handle_t *handle, struct ext4_renament *ent, ++ unsigned ino, unsigned file_type) ++{ ++ struct ext4_renament old = *ent; ++ int retval = 0; ++ ++ /* ++ * old->de could have moved from under us during make indexed dir, ++ * so the old->de may no longer valid and need to find it again ++ * before reset old inode info. ++ */ ++ old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL); ++ if (IS_ERR(old.bh)) ++ retval = PTR_ERR(old.bh); ++ if (!old.bh) ++ retval = -ENOENT; ++ if (retval) { ++ ext4_std_error(old.dir->i_sb, retval); ++ return; ++ } ++ ++ ext4_setent(handle, &old, ino, file_type); ++ brelse(old.bh); ++} ++ + static int ext4_find_delete_entry(handle_t *handle, struct inode *dir, + const struct qstr *d_name) + { +@@ -3926,8 +3951,8 @@ static int ext4_rename(struct inode *old + end_rename: + if (whiteout) { + if (retval) { +- ext4_setent(handle, &old, +- old.inode->i_ino, old_file_type); ++ ext4_resetent(handle, &old, ++ old.inode->i_ino, old_file_type); + drop_nlink(whiteout); + } + unlock_new_inode(whiteout); diff --git a/queue-5.10/ext4-fix-error-handling-in-ext4_end_enable_verity.patch b/queue-5.10/ext4-fix-error-handling-in-ext4_end_enable_verity.patch new file mode 100644 index 00000000000..9e90588f3f5 --- /dev/null +++ b/queue-5.10/ext4-fix-error-handling-in-ext4_end_enable_verity.patch @@ -0,0 +1,148 @@ +From f053cf7aa66cd9d592b0fc967f4d887c2abff1b7 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 2 Mar 2021 12:04:19 -0800 +Subject: ext4: fix error handling in ext4_end_enable_verity() + +From: Eric Biggers + +commit f053cf7aa66cd9d592b0fc967f4d887c2abff1b7 upstream. + +ext4 didn't properly clean up if verity failed to be enabled on a file: + +- It left verity metadata (pages past EOF) in the page cache, which + would be exposed to userspace if the file was later extended. + +- It didn't truncate the verity metadata at all (either from cache or + from disk) if an error occurred while setting the verity bit. + +Fix these bugs by adding a call to truncate_inode_pages() and ensuring +that we truncate the verity metadata (both from cache and from disk) in +all error paths. Also rework the code to cleanly separate the success +path from the error paths, which makes it much easier to understand. + +Reported-by: Yunlei He +Fixes: c93d8f885809 ("ext4: add basic fs-verity support") +Cc: stable@vger.kernel.org # v5.4+ +Signed-off-by: Eric Biggers +Link: https://lore.kernel.org/r/20210302200420.137977-2-ebiggers@kernel.org +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/verity.c | 93 +++++++++++++++++++++++++++++++++---------------------- + 1 file changed, 57 insertions(+), 36 deletions(-) + +--- a/fs/ext4/verity.c ++++ b/fs/ext4/verity.c +@@ -201,55 +201,76 @@ static int ext4_end_enable_verity(struct + struct inode *inode = file_inode(filp); + const int credits = 2; /* superblock and inode for ext4_orphan_del() */ + handle_t *handle; ++ struct ext4_iloc iloc; + int err = 0; +- int err2; + +- if (desc != NULL) { +- /* Succeeded; write the verity descriptor. */ +- err = ext4_write_verity_descriptor(inode, desc, desc_size, +- merkle_tree_size); +- +- /* Write all pages before clearing VERITY_IN_PROGRESS. */ +- if (!err) +- err = filemap_write_and_wait(inode->i_mapping); +- } ++ /* ++ * If an error already occurred (which fs/verity/ signals by passing ++ * desc == NULL), then only clean-up is needed. ++ */ ++ if (desc == NULL) ++ goto cleanup; + +- /* If we failed, truncate anything we wrote past i_size. */ +- if (desc == NULL || err) +- ext4_truncate(inode); ++ /* Append the verity descriptor. */ ++ err = ext4_write_verity_descriptor(inode, desc, desc_size, ++ merkle_tree_size); ++ if (err) ++ goto cleanup; + + /* +- * We must always clean up by clearing EXT4_STATE_VERITY_IN_PROGRESS and +- * deleting the inode from the orphan list, even if something failed. +- * If everything succeeded, we'll also set the verity bit in the same +- * transaction. ++ * Write all pages (both data and verity metadata). Note that this must ++ * happen before clearing EXT4_STATE_VERITY_IN_PROGRESS; otherwise pages ++ * beyond i_size won't be written properly. For crash consistency, this ++ * also must happen before the verity inode flag gets persisted. + */ ++ err = filemap_write_and_wait(inode->i_mapping); ++ if (err) ++ goto cleanup; + +- ext4_clear_inode_state(inode, EXT4_STATE_VERITY_IN_PROGRESS); ++ /* ++ * Finally, set the verity inode flag and remove the inode from the ++ * orphan list (in a single transaction). ++ */ + + handle = ext4_journal_start(inode, EXT4_HT_INODE, credits); + if (IS_ERR(handle)) { +- ext4_orphan_del(NULL, inode); +- return PTR_ERR(handle); ++ err = PTR_ERR(handle); ++ goto cleanup; + } + +- err2 = ext4_orphan_del(handle, inode); +- if (err2) +- goto out_stop; +- +- if (desc != NULL && !err) { +- struct ext4_iloc iloc; +- +- err = ext4_reserve_inode_write(handle, inode, &iloc); +- if (err) +- goto out_stop; +- ext4_set_inode_flag(inode, EXT4_INODE_VERITY); +- ext4_set_inode_flags(inode, false); +- err = ext4_mark_iloc_dirty(handle, inode, &iloc); +- } +-out_stop: ++ err = ext4_orphan_del(handle, inode); ++ if (err) ++ goto stop_and_cleanup; ++ ++ err = ext4_reserve_inode_write(handle, inode, &iloc); ++ if (err) ++ goto stop_and_cleanup; ++ ++ ext4_set_inode_flag(inode, EXT4_INODE_VERITY); ++ ext4_set_inode_flags(inode, false); ++ err = ext4_mark_iloc_dirty(handle, inode, &iloc); ++ if (err) ++ goto stop_and_cleanup; ++ + ext4_journal_stop(handle); +- return err ?: err2; ++ ++ ext4_clear_inode_state(inode, EXT4_STATE_VERITY_IN_PROGRESS); ++ return 0; ++ ++stop_and_cleanup: ++ ext4_journal_stop(handle); ++cleanup: ++ /* ++ * Verity failed to be enabled, so clean up by truncating any verity ++ * metadata that was written beyond i_size (both from cache and from ++ * disk), removing the inode from the orphan list (if it wasn't done ++ * already), and clearing EXT4_STATE_VERITY_IN_PROGRESS. ++ */ ++ truncate_inode_pages(inode->i_mapping, inode->i_size); ++ ext4_truncate(inode); ++ ext4_orphan_del(NULL, inode); ++ ext4_clear_inode_state(inode, EXT4_STATE_VERITY_IN_PROGRESS); ++ return err; + } + + static int ext4_get_verity_descriptor_location(struct inode *inode, diff --git a/queue-5.10/ext4-fix-potential-error-in-ext4_do_update_inode.patch b/queue-5.10/ext4-fix-potential-error-in-ext4_do_update_inode.patch new file mode 100644 index 00000000000..81922879dea --- /dev/null +++ b/queue-5.10/ext4-fix-potential-error-in-ext4_do_update_inode.patch @@ -0,0 +1,47 @@ +From 7d8bd3c76da1d94b85e6c9b7007e20e980bfcfe6 Mon Sep 17 00:00:00 2001 +From: Shijie Luo +Date: Fri, 12 Mar 2021 01:50:51 -0500 +Subject: ext4: fix potential error in ext4_do_update_inode + +From: Shijie Luo + +commit 7d8bd3c76da1d94b85e6c9b7007e20e980bfcfe6 upstream. + +If set_large_file = 1 and errors occur in ext4_handle_dirty_metadata(), +the error code will be overridden, go to out_brelse to avoid this +situation. + +Signed-off-by: Shijie Luo +Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com +Cc: stable@kernel.org +Reviewed-by: Jan Kara +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inode.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -5029,7 +5029,7 @@ static int ext4_do_update_inode(handle_t + struct ext4_inode_info *ei = EXT4_I(inode); + struct buffer_head *bh = iloc->bh; + struct super_block *sb = inode->i_sb; +- int err = 0, rc, block; ++ int err = 0, block; + int need_datasync = 0, set_large_file = 0; + uid_t i_uid; + gid_t i_gid; +@@ -5141,9 +5141,9 @@ static int ext4_do_update_inode(handle_t + bh->b_data); + + BUFFER_TRACE(bh, "call ext4_handle_dirty_metadata"); +- rc = ext4_handle_dirty_metadata(handle, NULL, bh); +- if (!err) +- err = rc; ++ err = ext4_handle_dirty_metadata(handle, NULL, bh); ++ if (err) ++ goto out_brelse; + ext4_clear_inode_state(inode, EXT4_STATE_NEW); + if (set_large_file) { + BUFFER_TRACE(EXT4_SB(sb)->s_sbh, "get write access"); diff --git a/queue-5.10/ext4-fix-rename-whiteout-with-fast-commit.patch b/queue-5.10/ext4-fix-rename-whiteout-with-fast-commit.patch new file mode 100644 index 00000000000..6b20d8da230 --- /dev/null +++ b/queue-5.10/ext4-fix-rename-whiteout-with-fast-commit.patch @@ -0,0 +1,102 @@ +From 8210bb29c1b66200cff7b25febcf6e39baf49fbf Mon Sep 17 00:00:00 2001 +From: Harshad Shirwadkar +Date: Tue, 16 Mar 2021 15:19:21 -0700 +Subject: ext4: fix rename whiteout with fast commit + +From: Harshad Shirwadkar + +commit 8210bb29c1b66200cff7b25febcf6e39baf49fbf upstream. + +This patch adds rename whiteout support in fast commits. Note that the +whiteout object that gets created is actually char device. Which +imples, the function ext4_inode_journal_mode(struct inode *inode) +would return "JOURNAL_DATA" for this inode. This has a consequence in +fast commit code that it will make creation of the whiteout object a +fast-commit ineligible behavior and thus will fall back to full +commits. With this patch, this can be observed by running fast commits +with rename whiteout and seeing the stats generated by ext4_fc_stats +tracepoint as follows: + +ext4_fc_stats: dev 254:32 fc ineligible reasons: +XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0, +RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16; +num_commits:6, ineligible: 6, numblks: 3 + +So in short, this patch guarantees that in case of rename whiteout, we +fall back to full commits. + +Amir mentioned that instead of creating a new whiteout object for +every rename, we can create a static whiteout object with irrelevant +nlink. That will make fast commits to not fall back to full +commit. But until this happens, this patch will ensure correctness by +falling back to full commits. + +Fixes: 8016e29f4362 ("ext4: fast commit recovery path") +Cc: stable@kernel.org +Signed-off-by: Harshad Shirwadkar +Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/ext4.h | 2 ++ + fs/ext4/fast_commit.c | 9 +++++++-- + fs/ext4/namei.c | 3 +++ + 3 files changed, 12 insertions(+), 2 deletions(-) + +--- a/fs/ext4/ext4.h ++++ b/fs/ext4/ext4.h +@@ -2762,6 +2762,8 @@ void __ext4_fc_track_link(handle_t *hand + struct dentry *dentry); + void ext4_fc_track_unlink(handle_t *handle, struct dentry *dentry); + void ext4_fc_track_link(handle_t *handle, struct dentry *dentry); ++void __ext4_fc_track_create(handle_t *handle, struct inode *inode, ++ struct dentry *dentry); + void ext4_fc_track_create(handle_t *handle, struct dentry *dentry); + void ext4_fc_track_inode(handle_t *handle, struct inode *inode); + void ext4_fc_mark_ineligible(struct super_block *sb, int reason); +--- a/fs/ext4/fast_commit.c ++++ b/fs/ext4/fast_commit.c +@@ -452,10 +452,10 @@ void ext4_fc_track_link(handle_t *handle + __ext4_fc_track_link(handle, d_inode(dentry), dentry); + } + +-void ext4_fc_track_create(handle_t *handle, struct dentry *dentry) ++void __ext4_fc_track_create(handle_t *handle, struct inode *inode, ++ struct dentry *dentry) + { + struct __track_dentry_update_args args; +- struct inode *inode = d_inode(dentry); + int ret; + + args.dentry = dentry; +@@ -466,6 +466,11 @@ void ext4_fc_track_create(handle_t *hand + trace_ext4_fc_track_create(inode, dentry, ret); + } + ++void ext4_fc_track_create(handle_t *handle, struct dentry *dentry) ++{ ++ __ext4_fc_track_create(handle, d_inode(dentry), dentry); ++} ++ + /* __track_fn for inode tracking */ + static int __track_inode(struct inode *inode, void *arg, bool update) + { +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -3864,6 +3864,7 @@ static int ext4_rename(struct inode *old + retval = ext4_mark_inode_dirty(handle, whiteout); + if (unlikely(retval)) + goto end_rename; ++ + } + if (!new.bh) { + retval = ext4_add_entry(handle, new.dentry, old.inode); +@@ -3937,6 +3938,8 @@ static int ext4_rename(struct inode *old + ext4_fc_track_unlink(handle, new.dentry); + __ext4_fc_track_link(handle, old.inode, new.dentry); + __ext4_fc_track_unlink(handle, old.inode, old.dentry); ++ if (whiteout) ++ __ext4_fc_track_create(handle, whiteout, old.dentry); + } + + if (new.inode) { diff --git a/queue-5.10/ext4-stop-inode-update-before-return.patch b/queue-5.10/ext4-stop-inode-update-before-return.patch new file mode 100644 index 00000000000..565817a8cc6 --- /dev/null +++ b/queue-5.10/ext4-stop-inode-update-before-return.patch @@ -0,0 +1,36 @@ +From 512c15ef05d73a04f1aef18a3bc61a8bb516f323 Mon Sep 17 00:00:00 2001 +From: Pan Bian +Date: Sun, 17 Jan 2021 00:57:32 -0800 +Subject: ext4: stop inode update before return + +From: Pan Bian + +commit 512c15ef05d73a04f1aef18a3bc61a8bb516f323 upstream. + +The inode update should be stopped before returing the error code. + +Signed-off-by: Pan Bian +Link: https://lore.kernel.org/r/20210117085732.93788-1-bianpan2016@163.com +Fixes: 8016e29f4362 ("ext4: fast commit recovery path") +Cc: stable@kernel.org +Reviewed-by: Harshad Shirwadkar +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inode.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -5385,8 +5385,10 @@ int ext4_setattr(struct dentry *dentry, + inode->i_gid = attr->ia_gid; + error = ext4_mark_inode_dirty(handle, inode); + ext4_journal_stop(handle); +- if (unlikely(error)) ++ if (unlikely(error)) { ++ ext4_fc_stop_update(inode); + return error; ++ } + } + + if (attr->ia_valid & ATTR_SIZE) { diff --git a/queue-5.10/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch b/queue-5.10/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch new file mode 100644 index 00000000000..56dbc95c131 --- /dev/null +++ b/queue-5.10/firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch @@ -0,0 +1,40 @@ +From 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 Mon Sep 17 00:00:00 2001 +From: Lv Yunlong +Date: Wed, 10 Mar 2021 00:31:27 -0800 +Subject: firmware/efi: Fix a use after bug in efi_mem_reserve_persistent + +From: Lv Yunlong + +commit 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 upstream. + +In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next +use the unmapped rsv. Use the unmapped pages will cause segment +fault. + +Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in unmapped memory") +Signed-off-by: Lv Yunlong +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/efi.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/firmware/efi/efi.c ++++ b/drivers/firmware/efi/efi.c +@@ -927,7 +927,7 @@ int __ref efi_mem_reserve_persistent(phy + } + + /* first try to find a slot in an existing linked list entry */ +- for (prsv = efi_memreserve_root->next; prsv; prsv = rsv->next) { ++ for (prsv = efi_memreserve_root->next; prsv; ) { + rsv = memremap(prsv, sizeof(*rsv), MEMREMAP_WB); + index = atomic_fetch_add_unless(&rsv->count, 1, rsv->size); + if (index < rsv->size) { +@@ -937,6 +937,7 @@ int __ref efi_mem_reserve_persistent(phy + memunmap(rsv); + return efi_mem_reserve_iomem(addr, size); + } ++ prsv = rsv->next; + memunmap(rsv); + } + diff --git a/queue-5.10/genirq-disable-interrupts-for-force-threaded-handlers.patch b/queue-5.10/genirq-disable-interrupts-for-force-threaded-handlers.patch new file mode 100644 index 00000000000..198fa521e84 --- /dev/null +++ b/queue-5.10/genirq-disable-interrupts-for-force-threaded-handlers.patch @@ -0,0 +1,70 @@ +From 81e2073c175b887398e5bca6c004efa89983f58d Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Wed, 17 Mar 2021 15:38:52 +0100 +Subject: genirq: Disable interrupts for force threaded handlers + +From: Thomas Gleixner + +commit 81e2073c175b887398e5bca6c004efa89983f58d upstream. + +With interrupt force threading all device interrupt handlers are invoked +from kernel threads. Contrary to hard interrupt context the invocation only +disables bottom halfs, but not interrupts. This was an oversight back then +because any code like this will have an issue: + +thread(irq_A) + irq_handler(A) + spin_lock(&foo->lock); + +interrupt(irq_B) + irq_handler(B) + spin_lock(&foo->lock); + +This has been triggered with networking (NAPI vs. hrtimers) and console +drivers where printk() happens from an interrupt which interrupted the +force threaded handler. + +Now people noticed and started to change the spin_lock() in the handler to +spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the +interrupt request which in turn breaks RT. + +Fix the root cause and not the symptom and disable interrupts before +invoking the force threaded handler which preserves the regular semantics +and the usefulness of the interrupt force threading as a general debugging +tool. + +For not RT this is not changing much, except that during the execution of +the threaded handler interrupts are delayed until the handler +returns. Vs. scheduling and softirq processing there is no difference. + +For RT kernels there is no issue. + +Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading") +Reported-by: Johan Hovold +Signed-off-by: Thomas Gleixner +Reviewed-by: Johan Hovold +Acked-by: Sebastian Andrzej Siewior +Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/irq/manage.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/kernel/irq/manage.c ++++ b/kernel/irq/manage.c +@@ -1072,11 +1072,15 @@ irq_forced_thread_fn(struct irq_desc *de + irqreturn_t ret; + + local_bh_disable(); ++ if (!IS_ENABLED(CONFIG_PREEMPT_RT)) ++ local_irq_disable(); + ret = action->thread_fn(action->irq, action->dev_id); + if (ret == IRQ_HANDLED) + atomic_inc(&desc->threads_handled); + + irq_finalize_oneshot(desc, action); ++ if (!IS_ENABLED(CONFIG_PREEMPT_RT)) ++ local_irq_enable(); + local_bh_enable(); + return ret; + } diff --git a/queue-5.10/maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch b/queue-5.10/maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch new file mode 100644 index 00000000000..bfb98a9e1d4 --- /dev/null +++ b/queue-5.10/maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch @@ -0,0 +1,57 @@ +From f8d70fd6a5a7a38a95eb8021e00d2e547f88efec Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Sat, 13 Mar 2021 14:58:02 +0100 +Subject: MAINTAINERS: move some real subsystems off of the staging mailing list +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Greg Kroah-Hartman + +commit f8d70fd6a5a7a38a95eb8021e00d2e547f88efec upstream. + +The VME and Android drivers still have their MAINTAINERS entries +pointing to the "driverdevel" mailing list, due to them having their +codebase move out of the drivers/staging/ directory, but no one +remembered to change the mailing list entries. + +Move them both to linux-kernel for lack of a more specific place at the +moment. These are both low-volume areas of the kernel, so this +shouldn't be an issue. + +Cc: Martyn Welch +Cc: Manohar Vanga +Cc: Arve Hjønnevåg +Cc: Todd Kjos +Cc: Martijn Coenen +Cc: Joel Fernandes +Cc: Christian Brauner +Cc: Hridya Valsaraju +Cc: Suren Baghdasaryan +Reported-by: Konstantin Ryabitsev +Link: https://lore.kernel.org/r/YEzE6u6U1jkBatmr@kroah.com +Signed-off-by: Greg Kroah-Hartman +--- + MAINTAINERS | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/MAINTAINERS ++++ b/MAINTAINERS +@@ -1155,7 +1155,7 @@ M: Joel Fernandes + M: Hridya Valsaraju + M: Suren Baghdasaryan +-L: devel@driverdev.osuosl.org ++L: linux-kernel@vger.kernel.org + S: Supported + T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git + F: drivers/android/ +@@ -18705,7 +18705,7 @@ VME SUBSYSTEM + M: Martyn Welch + M: Manohar Vanga + M: Greg Kroah-Hartman +-L: devel@driverdev.osuosl.org ++L: linux-kernel@vger.kernel.org + S: Maintained + T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git + F: Documentation/driver-api/vme.rst diff --git a/queue-5.10/maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch b/queue-5.10/maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch new file mode 100644 index 00000000000..0d4b27644fc --- /dev/null +++ b/queue-5.10/maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch @@ -0,0 +1,43 @@ +From e06da9ea3e3f6746a849edeae1d09ee821f5c2ce Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Tue, 16 Mar 2021 11:23:11 +0100 +Subject: MAINTAINERS: move the staging subsystem to lists.linux.dev + +From: Greg Kroah-Hartman + +commit e06da9ea3e3f6746a849edeae1d09ee821f5c2ce upstream. + +The drivers/staging/ tree has a new mailing list, +linux-staging@lists.linux.dev, so move the MAINTAINER entry to point to +it so that we get patches sent to the proper place. + +There was no need to specify a list for the hikey9xx driver, the tools +pick up the "base" list for drivers/staging/* so remove that line to +make the file simpler. + +Cc: Mauro Carvalho Chehab +Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + MAINTAINERS | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/MAINTAINERS ++++ b/MAINTAINERS +@@ -8001,7 +8001,6 @@ F: drivers/crypto/hisilicon/sec2/sec_mai + + HISILICON STAGING DRIVERS FOR HIKEY 960/970 + M: Mauro Carvalho Chehab +-L: devel@driverdev.osuosl.org + S: Maintained + F: drivers/staging/hikey9xx/ + +@@ -16665,7 +16664,7 @@ F: drivers/staging/vt665?/ + + STAGING SUBSYSTEM + M: Greg Kroah-Hartman +-L: devel@driverdev.osuosl.org ++L: linux-staging@lists.linux.dev + S: Supported + T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git + F: drivers/staging/ diff --git a/queue-5.10/series b/queue-5.10/series index 9f50521c8bf..9b0038843f2 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -141,3 +141,17 @@ x86-ioapic-ignore-irq2-again.patch kernel-fs-introduce-and-use-set_restart_fn-and-arch_set_restart_data.patch x86-move-ts_compat-back-to-asm-thread_info.h.patch x86-introduce-ts_compat_restart-to-fix-get_nr_restart_syscall.patch +efivars-respect-efi_unsupported-return-from-firmware.patch +ext4-fix-error-handling-in-ext4_end_enable_verity.patch +ext4-find-old-entry-again-if-failed-to-rename-whiteout.patch +ext4-stop-inode-update-before-return.patch +ext4-do-not-try-to-set-xattr-into-ea_inode-if-value-is-empty.patch +ext4-fix-potential-error-in-ext4_do_update_inode.patch +ext4-fix-rename-whiteout-with-fast-commit.patch +maintainers-move-some-real-subsystems-off-of-the-staging-mailing-list.patch +maintainers-move-the-staging-subsystem-to-lists.linux.dev.patch +static_call-fix-static_call_update-sanity-check.patch +efi-use-32-bit-alignment-for-efi_guid_t-literals.patch +firmware-efi-fix-a-use-after-bug-in-efi_mem_reserve_persistent.patch +genirq-disable-interrupts-for-force-threaded-handlers.patch +x86-apic-of-fix-cpu-devicetree-node-lookups.patch diff --git a/queue-5.10/static_call-fix-static_call_update-sanity-check.patch b/queue-5.10/static_call-fix-static_call_update-sanity-check.patch new file mode 100644 index 00000000000..313c42ef49b --- /dev/null +++ b/queue-5.10/static_call-fix-static_call_update-sanity-check.patch @@ -0,0 +1,67 @@ +From 38c93587375053c5b9ef093f4a5ea754538cba32 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 18 Mar 2021 11:31:51 +0100 +Subject: static_call: Fix static_call_update() sanity check + +From: Peter Zijlstra + +commit 38c93587375053c5b9ef093f4a5ea754538cba32 upstream. + +Sites that match init_section_contains() get marked as INIT. For +built-in code init_sections contains both __init and __exit text. OTOH +kernel_text_address() only explicitly includes __init text (and there +are no __exit text markers). + +Match what jump_label already does and ignore the warning for INIT +sites. Also see the excellent changelog for commit: 8f35eaa5f2de +("jump_label: Don't warn on __exit jump entries") + +Fixes: 9183c3f9ed710 ("static_call: Add inline static call infrastructure") +Reported-by: Sumit Garg +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Jarkko Sakkinen +Tested-by: Sumit Garg +Link: https://lkml.kernel.org/r/20210318113610.739542434@infradead.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/jump_label.c | 8 ++++++++ + kernel/static_call.c | 11 ++++++++++- + 2 files changed, 18 insertions(+), 1 deletion(-) + +--- a/kernel/jump_label.c ++++ b/kernel/jump_label.c +@@ -407,6 +407,14 @@ static bool jump_label_can_update(struct + return false; + + if (!kernel_text_address(jump_entry_code(entry))) { ++ /* ++ * This skips patching built-in __exit, which ++ * is part of init_section_contains() but is ++ * not part of kernel_text_address(). ++ * ++ * Skipping built-in __exit is fine since it ++ * will never be executed. ++ */ + WARN_ONCE(!jump_entry_is_init(entry), + "can't patch jump_label at %pS", + (void *)jump_entry_code(entry)); +--- a/kernel/static_call.c ++++ b/kernel/static_call.c +@@ -182,7 +182,16 @@ void __static_call_update(struct static_ + } + + if (!kernel_text_address((unsigned long)site_addr)) { +- WARN_ONCE(1, "can't patch static call site at %pS", ++ /* ++ * This skips patching built-in __exit, which ++ * is part of init_section_contains() but is ++ * not part of kernel_text_address(). ++ * ++ * Skipping built-in __exit is fine since it ++ * will never be executed. ++ */ ++ WARN_ONCE(!static_call_is_init(site), ++ "can't patch static call site at %pS", + site_addr); + continue; + } diff --git a/queue-5.10/x86-apic-of-fix-cpu-devicetree-node-lookups.patch b/queue-5.10/x86-apic-of-fix-cpu-devicetree-node-lookups.patch new file mode 100644 index 00000000000..49bb249aa74 --- /dev/null +++ b/queue-5.10/x86-apic-of-fix-cpu-devicetree-node-lookups.patch @@ -0,0 +1,51 @@ +From dd926880da8dbbe409e709c1d3c1620729a94732 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 12 Mar 2021 10:20:33 +0100 +Subject: x86/apic/of: Fix CPU devicetree-node lookups + +From: Johan Hovold + +commit dd926880da8dbbe409e709c1d3c1620729a94732 upstream. + +Architectures that describe the CPU topology in devicetree and do not have +an identity mapping between physical and logical CPU ids must override the +default implementation of arch_match_cpu_phys_id(). + +Failing to do so breaks CPU devicetree-node lookups using of_get_cpu_node() +and of_cpu_device_node_get() which several drivers rely on. It also causes +the CPU struct devices exported through sysfs to point to the wrong +devicetree nodes. + +On x86, CPUs are described in devicetree using their APIC ids and those +do not generally coincide with the logical ids, even if CPU0 typically +uses APIC id 0. + +Add the missing implementation of arch_match_cpu_phys_id() so that CPU-node +lookups work also with SMP. + +Apart from fixing the broken sysfs devicetree-node links this likely does +not affect current users of mainline kernels on x86. + +Fixes: 4e07db9c8db8 ("x86/devicetree: Use CPU description from Device Tree") +Signed-off-by: Johan Hovold +Signed-off-by: Thomas Gleixner +Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/apic/apic.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/kernel/apic/apic.c ++++ b/arch/x86/kernel/apic/apic.c +@@ -2317,6 +2317,11 @@ static int cpuid_to_apicid[] = { + [0 ... NR_CPUS - 1] = -1, + }; + ++bool arch_match_cpu_phys_id(int cpu, u64 phys_id) ++{ ++ return phys_id == cpuid_to_apicid[cpu]; ++} ++ + #ifdef CONFIG_SMP + /** + * apic_id_is_primary_thread - Check whether APIC ID belongs to a primary thread