Re: [syzbot ci] Re: ext4: deferred iput framework for EA inodes
Jan Kara <[email protected]> Thu, 9 Jul 2026 15:07:06 +0200
| Newsgroups | dev.linux.lists.syzbot,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <7gqptufc6arv6ichvx63rzrawxmb2mvlvn463xripjo3snhjgt@dc7bvpkrmogp> |
Hi Yun, On Tue 07-07-26 19:00:47, Zhou, Yun wrote: > On 7/3/26 22:02, Jan Kara wrote: > > > > On Thu 02-07-26 15:57:01, syzbot ci wrote: > > > syzbot ci has tested the following series > > > > > > [v13] ext4: deferred iput framework for EA inodes > > > https://lore.kernel.org/all/[email protected] > > > * [PATCH v13 1/4] fs: add iput_if_not_last() helper > > > * [PATCH v13 2/4] ext4: introduce ext4_put_ea_inode() for safe deferred iput > > > * [PATCH v13 3/4] ext4: convert all EA inode iput() calls to ext4_put_ea_inode() > > > * [PATCH v13 4/4] ext4: remove ea_inode_array mechanism in favor of ext4_put_ea_inode() > > > > > > and found the following issue: > > > WARNING in ext4_journal_check_start > > > > Good catch. We need to flush the pending work with iputs also in > > ext4_sync_fs() which should also take care of this race with remount > > read-only (and the same issue with filesystem freezing etc.). > > > > Sorry for the late reply—I missed it because I receive too many emails from > syzbot. I've now reconfigured my filtering rules. > > Regarding the issue reported by syzbot CI, would it be better to add > flush_delayed_work in __ext4_remount before sb->s_flags |= SB_RDONLY? That > would make the race window smaller. Well, if there is remount read-only happening, the operations modifying filesystem are blocked or made to fail (see mnt_get_write_access() / sb_prepare_remount_readonly()). So it doesn't really matter where in ext4_reconfigure() / __ext4_remount() we flush the work - no new items that are deleting any xattr inodes should be added. And placing the flushing into ext4_sync_fs() handles multiple similar problems - sync(2) should make sure all pending deletions are finished, remount needs to do this (and it calls sync_filesystem() which will end up calling ext4_sync_fs()), fsfreeze needs to do this (it calls sync_filesystem() as well). > Also, should I resend the v14 series, or submit a separate patch > specifically for this fix? I think you can resend with the fixup. Ted didn't merge the series yet. Honza -- Jan Kara <[email protected]> SUSE Labs, CR