On Mon, Apr 23, 2018 at 1:57 AM, Jan Kara <jack@xxxxxxx> wrote: > On Sun 22-04-18 09:12:10, Amir Goldstein wrote: >> If fs is frozen after mount and before the first file open, the >> update of s_last_mounted bypasses freeze protection and prints out >> a WARNING splat: >> >> $ mount /vdf >> $ fsfreeze -f /vdf >> $ cat /vdf/foo >> >> [ 31.578555] WARNING: CPU: 1 PID: 1415 at >> fs/ext4/ext4_jbd2.c:53 ext4_journal_check_start+0x48/0x82 >> >> [ 31.614016] Call Trace: >> [ 31.614997] __ext4_journal_start_sb+0xe4/0x1a4 >> [ 31.616771] ? ext4_file_open+0xb6/0x189 >> [ 31.618094] ext4_file_open+0xb6/0x189 >> >> This fix might not be free of open vs. freeze race, but it closes >> a big hole. >> >> [backport hint: to apply to stable tree, just need to repace >> sb_rdonly(sb) with (sb->s_flags & MS_RDONLY)] >> > > Thanks for the patch. But a proper (race-free) fix for this is to use > sb_start_intwrite(), before starting a handle and sb_end_intwrite() after > stopping it. > The thing is, it doesn't make sense reading a file will block because fs is frozen, does it? So a proper fix would probably involve a new helper sb_start_intwrite_trylock(), but I wasn't sure exactly, so posted this naiive version. So do you think sb_start_intwrite_trylock() would be good here? Thanks, Amir.
