| Message ID | 1524413530-23808-1-git-send-email-amir73il@gmail.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | ext4: do not update s_last_mounted of a frozen fs | expand |
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. Honza
On Mon, Apr 23, 2018 at 1:57 AM, Jan Kara <jack@suse.cz> 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.
On Mon 23-04-18 02:16:19, Amir Goldstein wrote: > On Mon, Apr 23, 2018 at 1:57 AM, Jan Kara <jack@suse.cz> 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? Yeah, better than your racy check... ;) Honza
diff --git a/fs/ext4/file.c b/fs/ext4/file.c index fb6f023622fe..b78e5e6c0e51 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -392,8 +392,8 @@ static int ext4_file_open(struct inode * inode, struct file * filp) if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb)))) return -EIO; - if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED) && - !sb_rdonly(sb))) { + if (unlikely(!(sbi->s_mount_flags & EXT4_MF_MNTDIR_SAMPLED)) && + !sb_rdonly(sb) && sb->s_writers.frozen == SB_UNFROZEN) { sbi->s_mount_flags |= EXT4_MF_MNTDIR_SAMPLED; /* * Sample where the filesystem has been mounted and
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)] Fixes: bc0b0d6d69ee ("ext4: update the s_last_mounted field in the superblock") Cc: <stable@vger.kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> --- fs/ext4/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)