--- /dev/null
+From f9c1f248607d5546075d3f731e7607d5571f2b60 Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Fri, 5 Aug 2022 20:39:47 +0800
+Subject: ext4: fix null-ptr-deref in ext4_write_info
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit f9c1f248607d5546075d3f731e7607d5571f2b60 upstream.
+
+I caught a null-ptr-deref bug as follows:
+==================================================================
+KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
+CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339
+RIP: 0010:ext4_write_info+0x53/0x1b0
+[...]
+Call Trace:
+ dquot_writeback_dquots+0x341/0x9a0
+ ext4_sync_fs+0x19e/0x800
+ __sync_filesystem+0x83/0x100
+ sync_filesystem+0x89/0xf0
+ generic_shutdown_super+0x79/0x3e0
+ kill_block_super+0xa1/0x110
+ deactivate_locked_super+0xac/0x130
+ deactivate_super+0xb6/0xd0
+ cleanup_mnt+0x289/0x400
+ __cleanup_mnt+0x16/0x20
+ task_work_run+0x11c/0x1c0
+ exit_to_user_mode_prepare+0x203/0x210
+ syscall_exit_to_user_mode+0x5b/0x3a0
+ do_syscall_64+0x59/0x70
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ ==================================================================
+
+Above issue may happen as follows:
+-------------------------------------
+exit_to_user_mode_prepare
+ task_work_run
+ __cleanup_mnt
+ cleanup_mnt
+ deactivate_super
+ deactivate_locked_super
+ kill_block_super
+ generic_shutdown_super
+ shrink_dcache_for_umount
+ dentry = sb->s_root
+ sb->s_root = NULL <--- Here set NULL
+ sync_filesystem
+ __sync_filesystem
+ sb->s_op->sync_fs > ext4_sync_fs
+ dquot_writeback_dquots
+ sb->dq_op->write_info > ext4_write_info
+ ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2)
+ d_inode(sb->s_root)
+ s_root->d_inode <--- Null pointer dereference
+
+To solve this problem, we use ext4_journal_start_sb directly
+to avoid s_root being used.
+
+Cc: stable@kernel.org
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20220805123947.565152-1-libaokun1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -5836,7 +5836,7 @@ static int ext4_write_info(struct super_
+ handle_t *handle;
+
+ /* Data block + inode block */
+- handle = ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2);
++ handle = ext4_journal_start_sb(sb, EXT4_HT_QUOTA, 2);
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ ret = dquot_commit_info(sb, type);
--- /dev/null
+From 3b575495ab8dbb4dbe85b4ac7f991693c3668ff5 Mon Sep 17 00:00:00 2001
+From: Lalith Rajendran <lalithkraj@google.com>
+Date: Thu, 18 Aug 2022 21:40:49 +0000
+Subject: ext4: make ext4_lazyinit_thread freezable
+
+From: Lalith Rajendran <lalithkraj@google.com>
+
+commit 3b575495ab8dbb4dbe85b4ac7f991693c3668ff5 upstream.
+
+ext4_lazyinit_thread is not set freezable. Hence when the thread calls
+try_to_freeze it doesn't freeze during suspend and continues to send
+requests to the storage during suspend, resulting in suspend failures.
+
+Cc: stable@kernel.org
+Signed-off-by: Lalith Rajendran <lalithkraj@google.com>
+Link: https://lore.kernel.org/r/20220818214049.1519544-1-lalithkraj@google.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/super.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -3157,6 +3157,7 @@ static int ext4_lazyinit_thread(void *ar
+ unsigned long next_wakeup, cur;
+
+ BUG_ON(NULL == eli);
++ set_freezable();
+
+ cont_thread:
+ while (true) {
--- /dev/null
+From d1052d236eddf6aa851434db1897b942e8db9921 Mon Sep 17 00:00:00 2001
+From: Jinke Han <hanjinke.666@bytedance.com>
+Date: Sat, 3 Sep 2022 09:24:29 +0800
+Subject: ext4: place buffer head allocation before handle start
+
+From: Jinke Han <hanjinke.666@bytedance.com>
+
+commit d1052d236eddf6aa851434db1897b942e8db9921 upstream.
+
+In our product environment, we encounter some jbd hung waiting handles to
+stop while several writters were doing memory reclaim for buffer head
+allocation in delay alloc write path. Ext4 do buffer head allocation with
+holding transaction handle which may be blocked too long if the reclaim
+works not so smooth. According to our bcc trace, the reclaim time in
+buffer head allocation can reach 258s and the jbd transaction commit also
+take almost the same time meanwhile. Except for these extreme cases,
+we often see several seconds delays for cgroup memory reclaim on our
+servers. This is more likely to happen considering docker environment.
+
+One thing to note, the allocation of buffer heads is as often as page
+allocation or more often when blocksize less than page size. Just like
+page cache allocation, we should also place the buffer head allocation
+before startting the handle.
+
+Cc: stable@kernel.org
+Signed-off-by: Jinke Han <hanjinke.666@bytedance.com>
+Link: https://lore.kernel.org/r/20220903012429.22555-1-hanjinke.666@bytedance.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inode.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -1317,6 +1317,13 @@ retry_grab:
+ page = grab_cache_page_write_begin(mapping, index, flags);
+ if (!page)
+ return -ENOMEM;
++ /*
++ * The same as page allocation, we prealloc buffer heads before
++ * starting the handle.
++ */
++ if (!page_has_buffers(page))
++ create_empty_buffers(page, inode->i_sb->s_blocksize, 0);
++
+ unlock_page(page);
+
+ retry_journal:
nilfs2-fix-use-after-free-bug-of-struct-nilfs_root.patch
jbd2-wake-up-journal-waiters-in-fifo-order-not-lifo.patch
ext4-avoid-crash-when-inline-data-creation-follows-dio-write.patch
+ext4-fix-null-ptr-deref-in-ext4_write_info.patch
+ext4-make-ext4_lazyinit_thread-freezable.patch
+ext4-place-buffer-head-allocation-before-handle-start.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
