This behavior is important in a scenario where a filesystem frozen using freeze_bdev() is thawed through the superblock level API; if we caused subsequent calls to thaw_bdev() future calls to freeze_bdev() would fail to freeze the superblock. We can get rid of this code away once bdev level fsfreeze and sb level fsfreeze are properly integrated. Cc: linux-fsdevel@xxxxxxxxxxxxxxx Cc: Josef Bacik <jbacik@xxxxxxxxxxxx> Cc: Eric Sandeen <sandeen@xxxxxxxxxx> Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx> Cc: Jan Kara <jack@xxxxxxx> Cc: Dave Chinner <dchinner@xxxxxxxxxx> Cc: Luiz Capitulino <lcapitulino@xxxxxxxxxx> Signed-off-by: Fernando Luis Vazquez Cao <fernando@xxxxxxxxxxxxx> --- diff -urNp linux-3.8-rc1-orig/fs/block_dev.c linux-3.8-rc1/fs/block_dev.c --- linux-3.8-rc1-orig/fs/block_dev.c 2012-12-25 11:52:04.344018000 +0900 +++ linux-3.8-rc1/fs/block_dev.c 2012-12-25 16:11:12.648018000 +0900 @@ -272,8 +272,19 @@ int thaw_bdev(struct block_device *bdev, } error = thaw_super(sb); - if (error) + /* + * If the superblock is already unfrozen, i.e. thaw_super() returned + * -EINVAL, we consider the block device level thaw successful. This + * behavior is important in a scenario where a filesystem frozen using + * freeze_bdev() is thawed through the superblock level API; if we + * caused the subsequent thaw_bdev() to fail bdev->bd_fsfreeze_count + * would not go back to 0 which means that future calls to freeze_bdev() + * would not freeze the superblock, just increase the counter. + */ + if (error && error != -EINVAL) bdev->bd_fsfreeze_count++; + else + error = 0; out: mutex_unlock(&bdev->bd_fsfreeze_mutex); return error; -- 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
