linux-kernel - Re: [PATCH] lightnvm: pblk: adjust the position of the lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ACAA275B-AC2C-4147-AF88-E250771CA1DD@cnexlabs.com>
Date:   Tue, 27 Nov 2018 14:24:03 +0000
From:   Javier Gonzalez <javier@...xlabs.com>
To:     Matias Bjørling <mb@...htnvm.io>
CC:     "suhua.tanke@...il.com" <suhua.tanke@...il.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lightnvm: pblk: adjust the position of the lock


> On 27 Nov 2018, at 15.22, Matias Bjørling <mb@...htnvm.io> wrote:
> 
> On 11/27/2018 01:57 PM, Javier Gonzalez wrote:
>>> On 27 Nov 2018, at 02.53, Hua Su <suhua.tanke@...il.com> wrote:
>>> 
>>> Add lock protection for list operations.
>>> Signed-off-by: Hua Su <suhua.tanke@...il.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