summaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorLaveesh Bansal <laveeshb@laveeshbansal.com>2026-02-03 15:19:34 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-02-06 16:44:25 +0100
commita11e76dff023a08086d606fe1d8def6b5564b308 (patch)
tree3470ad302177d8a30f30f5c8c78fb59617bc0eaa /Makefile
parent55558ab31d3c81874d0645e4f461afcb9bcce3bb (diff)
writeback: fix 100% CPU usage when dirtytime_expire_interval is 0
[ Upstream commit 543467d6fe97e27e22a26e367fda972dbefebbff ] When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshb@laveeshbansal.com> Link: https://patch.msgid.link/20260106145059.543282-2-laveeshb@laveeshbansal.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org> [ adapted system_percpu_wq to system_wq for the workqueue used in dirtytime_interval_handler() ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions