summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLachlan McIlroy <lmcilroy@redhat.com>2011-06-30 11:01:45 +1000
committerAl Viro <viro@zeniv.linux.org.uk>2011-08-01 01:57:44 -0400
commit782b94cdf577b4df1feb376f372dccc28e66a771 (patch)
treee0ea0054539a695707f4e54aacdb0c53cd990076
parentc4ae0c65455c1bb30d1b71c6dd9a1a62aadde8ef (diff)
downloadlinux-782b94cdf577b4df1feb376f372dccc28e66a771.tar.gz
linux-782b94cdf577b4df1feb376f372dccc28e66a771.tar.bz2
linux-782b94cdf577b4df1feb376f372dccc28e66a771.zip
block: initialise bd_super in bdget()
bd_super is currently reset to NULL in kill_block_super() so we rely on previous users of the block_device object to initialise this value for the next user. This quirk was exposed on RHEL5 when a third party filesystem did not always use kill_block_super() and therefore bd_super wasn't being reset when a block_device object was recycled within the cache. This may not be a problem upstream but makes sense to be defensive. Signed-off-by: Lachlan McIlroy <lmcilroy@redhat.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
-rw-r--r--fs/block_dev.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/block_dev.c b/fs/block_dev.c
index f55aad4d1611..f28680553288 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -552,6 +552,7 @@ struct block_device *bdget(dev_t dev)
if (inode->i_state & I_NEW) {
bdev->bd_contains = NULL;
+ bdev->bd_super = NULL;
bdev->bd_inode = inode;
bdev->bd_block_size = (1 << inode->i_blkbits);
bdev->bd_part_count = 0;