On 08 Apr 2021 at 06:26, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > While running a new fstest that races a readonly remount with scrub > running in repair mode, I observed the kernel tripping over debugging > assertions in the log quiesce code that were checking that the CIL was > empty. When the sysadmin runs scrub in repair mode, the scrub code > allocates real transactions (with reservations) to change things, but > doesn't increment the superblock writers count to block a readonly > remount attempt while it is running. > > We don't require the userspace caller to have a writable file descriptor > to run repairs, so we have to call mnt_want_write_file to obtain freeze > protection and increment the writers count. It's ok to remove the call > to sb_start_write for the dry-run case because commit 8321ddb2fa29 > removed the behavior where scrub and fsfreeze fight over the buffer LRU. I see that, during remount process, sb_prepare_remount_readonly() depends on the value of mnt_get_writers() to determine if it has to abort remount. However, sb_start_write() (used by xfs_scrub_metadata()) will only obtain the semaphore at sb->s_writers.rw_sem[1]. Hence a task running scrub in repair mode would not be able prevent another task from remounting the filesystem into a read-only state. mnt_want_write_file() is the right fix since it increments the mnt writer count and also prevents the filesystem from getting frozen. Hence, Reviewed-by: Chandan Babu R <chandanrlinux@xxxxxxxxx> -- chandan
