--- /dev/null
+From fb98cc0b3af2ba4d87301dff2b381b12eee35d7d Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Wed, 10 Mar 2021 08:33:19 +0100
+Subject: efi: use 32-bit alignment for efi_guid_t literals
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+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 <nathan@kernel.org>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://github.com/ClangBuiltLinux/linux/issues/1327
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 483028edacab374060d93955382b4865a9e07cba Mon Sep 17 00:00:00 2001
+From: Shawn Guo <shawn.guo@linaro.org>
+Date: Wed, 17 Mar 2021 14:36:06 +0800
+Subject: efivars: respect EFI_UNSUPPORTED return from firmware
+
+From: Shawn Guo <shawn.guo@linaro.org>
+
+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: <stable@vger.kernel.org> # v5.10+
+Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From 6b22489911b726eebbf169caee52fea52013fbdd Mon Sep 17 00:00:00 2001
+From: "zhangyi (F)" <yi.zhang@huawei.com>
+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) <yi.zhang@huawei.com>
+
+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) <yi.zhang@huawei.com>
+Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From b7ff91fd030dc9d72ed91b1aab36e445a003af4f Mon Sep 17 00:00:00 2001
+From: "zhangyi (F)" <yi.zhang@huawei.com>
+Date: Wed, 3 Mar 2021 21:17:02 +0800
+Subject: ext4: find old entry again if failed to rename whiteout
+
+From: zhangyi (F) <yi.zhang@huawei.com>
+
+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) <yi.zhang@huawei.com>
+Link: https://lore.kernel.org/r/20210303131703.330415-1-yi.zhang@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From f053cf7aa66cd9d592b0fc967f4d887c2abff1b7 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 2 Mar 2021 12:04:19 -0800
+Subject: ext4: fix error handling in ext4_end_enable_verity()
+
+From: Eric Biggers <ebiggers@google.com>
+
+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 <heyunlei@hihonor.com>
+Fixes: c93d8f885809 ("ext4: add basic fs-verity support")
+Cc: stable@vger.kernel.org # v5.4+
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Link: https://lore.kernel.org/r/20210302200420.137977-2-ebiggers@kernel.org
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 7d8bd3c76da1d94b85e6c9b7007e20e980bfcfe6 Mon Sep 17 00:00:00 2001
+From: Shijie Luo <luoshijie1@huawei.com>
+Date: Fri, 12 Mar 2021 01:50:51 -0500
+Subject: ext4: fix potential error in ext4_do_update_inode
+
+From: Shijie Luo <luoshijie1@huawei.com>
+
+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 <luoshijie1@huawei.com>
+Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com
+Cc: stable@kernel.org
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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");
--- /dev/null
+From 8210bb29c1b66200cff7b25febcf6e39baf49fbf Mon Sep 17 00:00:00 2001
+From: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
+Date: Tue, 16 Mar 2021 15:19:21 -0700
+Subject: ext4: fix rename whiteout with fast commit
+
+From: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
+
+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 <harshadshirwadkar@gmail.com>
+Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 512c15ef05d73a04f1aef18a3bc61a8bb516f323 Mon Sep 17 00:00:00 2001
+From: Pan Bian <bianpan2016@163.com>
+Date: Sun, 17 Jan 2021 00:57:32 -0800
+Subject: ext4: stop inode update before return
+
+From: Pan Bian <bianpan2016@163.com>
+
+commit 512c15ef05d73a04f1aef18a3bc61a8bb516f323 upstream.
+
+The inode update should be stopped before returing the error code.
+
+Signed-off-by: Pan Bian <bianpan2016@163.com>
+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 <harshadshirwadkar@gmail.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 Mon Sep 17 00:00:00 2001
+From: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
+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 <lyl2019@mail.ustc.edu.cn>
+
+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 <lyl2019@mail.ustc.edu.cn>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From 81e2073c175b887398e5bca6c004efa89983f58d Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 17 Mar 2021 15:38:52 +0100
+Subject: genirq: Disable interrupts for force threaded handlers
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <johan@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Johan Hovold <johan@kernel.org>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From f8d70fd6a5a7a38a95eb8021e00d2e547f88efec Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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 <gregkh@linuxfoundation.org>
+
+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 <martyn@welchs.me.uk>
+Cc: Manohar Vanga <manohar.vanga@gmail.com>
+Cc: Arve Hjønnevåg <arve@android.com>
+Cc: Todd Kjos <tkjos@android.com>
+Cc: Martijn Coenen <maco@android.com>
+Cc: Joel Fernandes <joel@joelfernandes.org>
+Cc: Christian Brauner <christian@brauner.io>
+Cc: Hridya Valsaraju <hridya@google.com>
+Cc: Suren Baghdasaryan <surenb@google.com>
+Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
+Link: https://lore.kernel.org/r/YEzE6u6U1jkBatmr@kroah.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ MAINTAINERS | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/MAINTAINERS
++++ b/MAINTAINERS
+@@ -1155,7 +1155,7 @@ M: Joel Fernandes <joel@joelfernandes.or
+ M: Christian Brauner <christian@brauner.io>
+ M: Hridya Valsaraju <hridya@google.com>
+ M: Suren Baghdasaryan <surenb@google.com>
+-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 <martyn@welchs.me.uk>
+ M: Manohar Vanga <manohar.vanga@gmail.com>
+ M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+-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
--- /dev/null
+From e06da9ea3e3f6746a849edeae1d09ee821f5c2ce Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Tue, 16 Mar 2021 11:23:11 +0100
+Subject: MAINTAINERS: move the staging subsystem to lists.linux.dev
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+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 <mchehab+huawei@kernel.org>
+Link: https://lore.kernel.org/r/20210316102311.182375-1-gregkh@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <mchehab+huawei@kernel.org>
+-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 <gregkh@linuxfoundation.org>
+-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/
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
--- /dev/null
+From 38c93587375053c5b9ef093f4a5ea754538cba32 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Thu, 18 Mar 2021 11:31:51 +0100
+Subject: static_call: Fix static_call_update() sanity check
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <sumit.garg@linaro.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
+Tested-by: Sumit Garg <sumit.garg@linaro.org>
+Link: https://lkml.kernel.org/r/20210318113610.739542434@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From dd926880da8dbbe409e709c1d3c1620729a94732 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 12 Mar 2021 10:20:33 +0100
+Subject: x86/apic/of: Fix CPU devicetree-node lookups
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <johan@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/r/20210312092033.26317-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
