Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200515021731.cb5y557wsxf66fo3@debian.debian-2> <SN4PR0401MB35985CFC199D20362EBFD8E09BBD0@SN4PR0401MB3598.namprd04.prod.outlook.com>
In-Reply-To: <SN4PR0401MB35985CFC199D20362EBFD8E09BBD0@SN4PR0401MB3598.namprd04.prod.outlook.com>
From:   Bo YU <tsu.yubo@gmail.com>
Date:   Fri, 15 May 2020 17:23:56 +0800
Message-ID: <CAKq8=3KyewqQLdo-GjERuOfKe5ZrmQ+bRPfFRWiyZkjdEVvSeA@mail.gmail.com>
Subject: Re: [PATCH -next] fs/btrfs: Fix unlocking in btrfs_ref_tree_mod
To:     Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc:     "clm@fb.com" <clm@fb.com>,
        "josef@toxicpanda.com" <josef@toxicpanda.com>,
        "sterba@suse.com" <sterba@suse.com>,
        "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,
On Fri, May 15, 2020 at 5:03 PM Johannes Thumshirn
<Johannes.Thumshirn@wdc.com> wrote:
>
> On 15/05/2020 04:17, Bo YU wrote:
> > It adds spin_lock() in add_block_entry() but out path does not unlock
> > it.
>
> Which call path doesn't unlock it? There is an out_unlock label with a
> spin_unlock() right above your insert. So either coverity messed something
> up or the call path that needs the unlock has to jump to out_unlock instead
> of out.
This is out label without unlocking it. It will be offered spin_lock
in add_block_entry()
for be. But here I was worried about that unlock it in if() whether it
is right or not.