Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] lightnvm: pblk: adjust the position of the lock
To:     javier@cnexlabs.com
Cc:     suhua.tanke@gmail.com, axboe@kernel.dk,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20181127015309.2374-1-suhua.tanke@gmail.com>
 <F75BC3C7-FACE-4C04-A9BE-5A3AA25D3466@cnexlabs.com>
 <a53eb78d-90d3-f84e-a0bf-9acbc32671f4@lightnvm.io>
 <ACAA275B-AC2C-4147-AF88-E250771CA1DD@cnexlabs.com>
From:   =?UTF-8?Q?Matias_Bj=c3=b8rling?= <mb@lightnvm.io>
Message-ID: <55a08621-53cd-66b0-5b31-ca2bd6b26861@lightnvm.io>
Date:   Tue, 27 Nov 2018 15:26:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <ACAA275B-AC2C-4147-AF88-E250771CA1DD@cnexlabs.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/27/2018 03:24 PM, Javier Gonzalez wrote:
> 
>> On 27 Nov 2018, at 15.22, Matias Bjørling <mb@lightnvm.io> wrote:
>>
>> On 11/27/2018 01:57 PM, Javier Gonzalez wrote:
>>>> On 27 Nov 2018, at 02.53, Hua Su <suhua.tanke@gmail.com> wrote:
>>>>
>>>> Add lock protection for list operations.
>>>> Signed-off-by: Hua Su <suhua.tanke@gmail.com>
>>>> ---
>>>> drivers/lightnvm/pblk-core.c | 17 ++++++++++-------
>>>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
>>>> index 6944aac43b01..e490df217dac 100644
>>>> --- a/drivers/lightnvm/pblk-core.c
>>>> +++ b/drivers/lightnvm/pblk-core.c
>>>> @@ -1286,24 +1286,27 @@ int pblk_line_recov_alloc(struct pblk *pblk, struct pblk_line *line)
>>>>     list_del(&line->list);
>>>>
>>>>     ret = pblk_line_prepare(pblk, line);
>>>> -    if (ret) {
>>>> -        list_add(&line->list, &l_mg->free_list);
>>>> -        spin_unlock(&l_mg->free_lock);
>>>> -        return ret;
>>>> -    }
>>>> -    spin_unlock(&l_mg->free_lock);
>>>> +    if (ret)
>>>> +        goto out;
>>>>
>>>>     ret = pblk_line_alloc_bitmaps(pblk, line);
>>>>     if (ret)
>>>> -        return ret;
>>>> +        goto out;
>>>>
>>>>     if (!pblk_line_init_bb(pblk, line, 0)) {
>>>>         list_add(&line->list, &l_mg->free_list);
>>>> +        spin_unlock(&l_mg->free_lock);
>>>>         return -EINTR;
>>>>     }
>>>> +    spin_unlock(&l_mg->free_lock);
>>>>
>>>>     pblk_rl_free_lines_dec(&pblk->rl, line, true);
>>>>     return 0;
>>>> +
>>>> +out:
>>>> +    list_add(&line->list, &l_mg->free_list);
>>>> +    spin_unlock(&l_mg->free_lock);
>>>> +    return ret;
>>>> }
>>>>
>>>> void pblk_line_recov_close(struct pblk *pblk, struct pblk_line *line)
>>>> --
>>>> 2.19.1
>>> This path is only touched by the recovery path, which is single
>>> threaded, so there is no race condition as is. Also, if recovery fails,
>>> pblk will not create the instance at all. This said, it would be
>>> good to protect the list_add on the pblk_line_init_bb() error path in
>>> case this code is used for some other purpose in the future.
>>
>> I like your explanation here. Another option is that we could add a comment to notify the developer that it safe in this context?
> 
> Sure. Do you want to add it? Or should I send it?
> 
> Javier
> 

Please send it. Thanks!