- To: Jan Schmidt <list.btrfs@xxxxxxxxxxxxx>
- Subject: Re: [patch 1/2] Btrfs: double unlock bug in error handling
- From: David Sterba <dave@xxxxxxxx>
- Date: Wed, 18 Apr 2012 13:58:42 +0200
- Cc: Dan Carpenter <dan.carpenter@xxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, Jeff Mahoney <jeffm@xxxxxxxx>, linux-btrfs@xxxxxxxxxxxxxxx, kernel-janitors@xxxxxxxxxxxxxxx
- In-reply-to: <4F8EA5AA.2080202@jan-o-sch.net>
- Mail-followup-to: Jan Schmidt <list.btrfs@xxxxxxxxxxxxx>, Dan Carpenter <dan.carpenter@xxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>, Jeff Mahoney <jeffm@xxxxxxxx>, linux-btrfs@xxxxxxxxxxxxxxx, kernel-janitors@xxxxxxxxxxxxxxx
- Reply-to: dave@xxxxxxxx
- User-agent: Mutt/1.5.21 (2011-07-01)
On Wed, Apr 18, 2012 at 01:29:46PM +0200, Jan Schmidt wrote:
> I think the correct way to fix this is:
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index a844204..9af261a 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -2450,7 +2450,6 @@ again:
>
> ret = run_clustered_refs(trans, root, &cluster);
> if (ret < 0) {
> - spin_unlock(&delayed_refs->lock);
> btrfs_abort_transaction(trans, root, ret);
> return ret;
> }
That's another way to fix it, but I'd rather see the lock/unlock
balanced within a function, and in this case the extra lock does not
hurt as it's a rare codepath.
david
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Netdev]
[Kernel Newbies]
[Share Photos]
[IDE]
[Security]
[Git]
[Netfilter]
[Bugtraq]
[Photo]
[Yosemite]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Linux ATA RAID]
[Samba]
[Video 4 Linux]
[Device Mapper]
[Linux Resources]
[Free Dating]