On Thu, Jun 15, 2023 at 01:38:48PM +0200, Jan Kara wrote: > The reconfigure / remount code takes a lot of effort to protect > filesystem's reconfiguration code from racing writes on remounting > read-only. However during remounting read-only filesystem to read-write > mode userspace writes can start immediately once we clear SB_RDONLY > flag. This is inconvenient for example for ext4 because we need to do > some writes to the filesystem (such as preparation of quota files) > before we can take userspace writes so we are clearing SB_RDONLY flag > before we are fully ready to accept userpace writes and syzbot has found > a way to exploit this [1]. Also as far as I'm reading the code > the filesystem remount code was protected from racing writes in the > legacy mount path by the mount's MNT_READONLY flag so this is relatively > new problem. It is actually fairly easy to protect remount read-write > from racing writes using sb->s_readonly_remount flag so let's just do > that instead of having to workaround these races in the filesystem code. > > [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@xxxxxxxxxx/T/ > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- So looking at the ext4 code this can only happen when you clear SB_RDONLY in ->reconfigure() too early (and the mount isn't MNT_READONLY). Afaict, this was fixed in: a44be64bbecb ("ext4: don't clear SB_RDONLY when remounting r/w until quota is re-enabled") by clearing SB_RDONLY late, right before returning from ->reconfigure() when everything's ready. So your change is not about fixing that bug in [1] it's about making the vfs give the guarantee that an fs is free to clear SB_RDONLY because any ro<->rw transitions are protected via s_readonly_remount. Correct? It seems ok to me just making sure.
