f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()

syzbot reports a f2fs bug as below:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
destroy_super_work+0xec/0x130 fs/super.c:282
process_one_work kernel/workqueue.c:3231 [inline]
process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb->s_umount semaphore via remount procedure, then below
race condition causes this bug:

• freeze_super()
• sb_wait_write(sb, SB_FREEZE_WRITE)
• sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
• sb_wait_write(sb, SB_FREEZE_FS)
  - f2fs_handle_critical_error
  - sb->s_flags |= SB_RDONLY
• thaw_super
• thaw_super_locked
• sb_rdonly() is true, so it skips
  sb_freeze_unlock(sb, SB_FREEZE_FS)
• deactivate_locked_supe…