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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
