Patch "quota: flush quota_release_work upon quota writeback" has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    quota: flush quota_release_work upon quota writeback

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     quota-flush-quota_release_work-upon-quota-writeback.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 17d791af230e4d916546701f4a8fc7566f8ea922
Author: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx>
Date:   Thu Nov 21 18:08:54 2024 +0530

    quota: flush quota_release_work upon quota writeback
    
    [ Upstream commit ac6f420291b3fee1113f21d612fa88b628afab5b ]
    
    One of the paths quota writeback is called from is:
    
    freeze_super()
      sync_filesystem()
        ext4_sync_fs()
          dquot_writeback_dquots()
    
    Since we currently don't always flush the quota_release_work queue in
    this path, we can end up with the following race:
    
     1. dquot are added to releasing_dquots list during regular operations.
     2. FS Freeze starts, however, this does not flush the quota_release_work queue.
     3. Freeze completes.
     4. Kernel eventually tries to flush the workqueue while FS is frozen which
        hits a WARN_ON since transaction gets started during frozen state:
    
      ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)
      __ext4_journal_start_sb+0x64/0x1c0 [ext4]
      ext4_release_dquot+0x90/0x1d0 [ext4]
      quota_release_workfn+0x43c/0x4d0
    
    Which is the following line:
    
      WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);
    
    Which ultimately results in generic/390 failing due to dmesg
    noise. This was detected on powerpc machine 15 cores.
    
    To avoid this, make sure to flush the workqueue during
    dquot_writeback_dquots() so we dont have any pending workitems after
    freeze.
    
    Reported-by: Disha Goel <disgoel@xxxxxxxxxxxxx>
    CC: stable@xxxxxxxxxxxxxxx
    Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
    Reviewed-by: Baokun Li <libaokun1@xxxxxxxxxx>
    Signed-off-by: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx>
    Signed-off-by: Jan Kara <jack@xxxxxxx>
    Link: https://patch.msgid.link/20241121123855.645335-2-ojaswin@xxxxxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index 23dbde1de2520..67562c78e57d5 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -690,6 +690,8 @@ int dquot_writeback_dquots(struct super_block *sb, int type)
 
 	WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount));
 
+	flush_delayed_work(&quota_release_work);
+
 	for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
 		if (type != -1 && cnt != type)
 			continue;




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux