* [PATCH 1/2] btrfs: brelse in error path in open_ctree
@ 2013-08-09 20:37 Zach Brown
2013-08-09 20:37 ` [PATCH 2/2] btrfs: don't double brelse on device rm Zach Brown
0 siblings, 1 reply; 3+ messages in thread
From: Zach Brown @ 2013-08-09 20:37 UTC (permalink / raw)
To: linux-btrfs
Commit 1104a8855 added an error branch that forgot to release the super
bh. I found this while looking for an unrelated double brelse.
Signed-off-by: Zach Brown <zab@redhat.com>
---
fs/btrfs/disk-io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 254cdc8..ca1e25f 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2329,6 +2329,7 @@ int open_ctree(struct super_block *sb,
if (btrfs_check_super_csum(bh->b_data)) {
printk(KERN_ERR "btrfs: superblock checksum mismatch\n");
err = -EINVAL;
+ brelse(bh);
goto fail_alloc;
}
--
1.7.11.7
^ permalink raw reply related [flat|nested] 3+ messages in thread* [PATCH 2/2] btrfs: don't double brelse on device rm
2013-08-09 20:37 [PATCH 1/2] btrfs: brelse in error path in open_ctree Zach Brown
@ 2013-08-09 20:37 ` Zach Brown
2013-08-09 21:05 ` Josef Bacik
0 siblings, 1 reply; 3+ messages in thread
From: Zach Brown @ 2013-08-09 20:37 UTC (permalink / raw)
To: linux-btrfs
Device removal currently causes bdev removal to try to double free a bh
in the bdev:
[ 55.714833] WARNING: at fs/buffer.c:1160 __brelse+0x36/0x40()
[ 55.714833] VFS: brelse: Trying to free free buffer
Commit 7e3d9ebb1 added a double release of the bh for a device being
removed when all the supers don't fit in the device. In that case it
releases the bh assuming that it's going to read a new one, finds that
it won't read, and goes to a label that releases the bh again.
All it needed to do was only brelse() right before overwriting the
current bh with __bread().
Signed-off-by: Zach Brown <zab@redhat.com>
---
fs/btrfs/volumes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 090f57c..adb0bca 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1656,11 +1656,12 @@ int btrfs_rm_device(struct btrfs_root *root, char *device_path)
* the below would take of the rest
*/
for (i = 1; i < BTRFS_SUPER_MIRROR_MAX; i++) {
- brelse(bh);
bytenr = btrfs_sb_offset(i);
if (bytenr + BTRFS_SUPER_INFO_SIZE >=
i_size_read(bdev->bd_inode))
break;
+
+ brelse(bh);
bh = __bread(bdev, bytenr / 4096,
BTRFS_SUPER_INFO_SIZE);
if (!bh)
--
1.7.11.7
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH 2/2] btrfs: don't double brelse on device rm
2013-08-09 20:37 ` [PATCH 2/2] btrfs: don't double brelse on device rm Zach Brown
@ 2013-08-09 21:05 ` Josef Bacik
0 siblings, 0 replies; 3+ messages in thread
From: Josef Bacik @ 2013-08-09 21:05 UTC (permalink / raw)
To: Zach Brown; +Cc: linux-btrfs
On Fri, Aug 09, 2013 at 01:37:14PM -0700, Zach Brown wrote:
> Device removal currently causes bdev removal to try to double free a bh
> in the bdev:
>
> [ 55.714833] WARNING: at fs/buffer.c:1160 __brelse+0x36/0x40()
> [ 55.714833] VFS: brelse: Trying to free free buffer
>
> Commit 7e3d9ebb1 added a double release of the bh for a device being
> removed when all the supers don't fit in the device. In that case it
> releases the bh assuming that it's going to read a new one, finds that
> it won't read, and goes to a label that releases the bh again.
>
> All it needed to do was only brelse() right before overwriting the
> current bh with __bread().
I've dropped this patch so we don't need this anymore. Thanks,
Josef
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-08-09 21:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-09 20:37 [PATCH 1/2] btrfs: brelse in error path in open_ctree Zach Brown
2013-08-09 20:37 ` [PATCH 2/2] btrfs: don't double brelse on device rm Zach Brown
2013-08-09 21:05 ` Josef Bacik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).