Re: [PATCH 1/7] fsfreeze: Prevent emergency thaw from looping infinitely

[Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>]

On 2012/07/10 21:08, Jan Kara wrote:

> On Tue 10-07-12 17:20:57, Fernando Luis Vázquez Cao wrote:
>> The thawing of a filesystem through sysrq-j loops infinitely as it
>> incorrectly detects a thawed filesytsem as frozen and tries to
>> unfreeze repeatedly. This is a regression caused by
>> 4504230a71566785a05d3e6b53fa1ee071b864eb ("freeze_bdev: grab active
>> reference to frozen superblocks") in that it no longer returned
>> -EINVAL for superblocks that were not frozen.
>    Umm, I don't think above mentioned commit is really guilty.

Well, it is after that commit that

-       if (!bdev->bd_fsfreeze_count) {
-               mutex_unlock(&bdev->bd_fsfreeze_mutex);
-               return -EINVAL;
-       }

became

+       if (!bdev->bd_fsfreeze_count)
+               goto out_unlock;
[...]
+out_unlock:
         mutex_unlock(&bdev->bd_fsfreeze_mutex);
         return 0;

which breaks emergency thaw.


> Also I think your patch breaks thawing of a block device without mounted
> filesystem - you end up returning EINVAL for that...

It returns EINVAL only after the last thaw and the block device
is still properly thawed (i.e. bd_fsfreeze_count becomes 0). Things
work because the only place where the kernel checks the return
value of thaw_bdev is emergency thaw (the freeze ioctls use the sb
level API). That said for the sake of readability I could change the
code to return 0 when sb == NULL (either as a follow-up patch
or as part of a rebase to your tree or Al's).

Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html