On Wed 11-07-12 11:25:56, Fernando Luis Vazquez Cao wrote:
> 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.
Ah, OK. I misread the code... Sorry for the noise.
> >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).
Yes, after your patch thaw_bdev() returns EINVAL although the device is
thawed. That is just wrong regardless whether any caller cares or not. And
before your patch this was working correctly. So please fix your patch.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
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
