Re: [PATCH] ext4: do not update s_last_mounted of a frozen fs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux