Re: [PATCH] xfs: fix scrub and remount-ro protection when running scrub

[Chandan Babu R <chandanrlinux@gmail.com>]

On 08 Apr 2021 at 06:26, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> 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@gmail.com>

-- 
chandan