linux-kernel - Re: [PATCH V2] lightnvm: pblk: take write semaphore on metadata

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9526B6A2-7DE5-467B-B4E4-D5B51BCFB242@cnexlabs.com>
Date:   Sat, 4 Aug 2018 18:37:59 +0000
From:   Javier Gonzalez <javier@...xlabs.com>
To:     Matias Bjørling <mb@...htnvm.io>
CC:     "javier@...igon.com" <javier@...igon.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 V2] lightnvm: pblk: take write semaphore on metadata



> On 4 Aug 2018, at 20.35, Matias Bjørling <mb@...htnvm.io> wrote:
> 
>> On 08/03/2018 03:30 PM, Javier González wrote:
>> # Changes singe V1:
>>   - Fix double I/O on the read path (by Matias)
>>   - Improve commit message (by Jens)
>> pblk guarantees write ordering at a chunk level through a per open chunk
>> semaphore. At this point, since we only have an open I/O stream for both
>> user and GC data, the semaphore is per parallel unit.
>> Since metadata I/O is synchronous, the semaphore is not needed as
>> ordering is guaranteed. However, if the metadata scheme changes or
>> multiple streams are open, this guarantee might not be preserved.
>> This patch makes sure that all writes go through the semaphore, even for
>> synchronous I/O. This is consistent with pblk's write I/O model. It also
>> simplifies maintenance since changes in the metdatada scheme could cause
>> ordering issues.
>> Signed-off-by: Javier González <javier@...xlabs.com>
>> ---
>>  drivers/lightnvm/pblk-core.c | 18 ++++++++++++++++--
>>  drivers/lightnvm/pblk.h      |  1 +
>>  2 files changed, 17 insertions(+), 2 deletions(-)
>> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
>> index 00984b486fea..6432faf5b19c 100644
>> --- a/drivers/lightnvm/pblk-core.c
>> +++ b/drivers/lightnvm/pblk-core.c
>> @@ -493,6 +493,20 @@ int pblk_submit_io_sync(struct pblk *pblk, struct nvm_rq *rqd)
>>      return nvm_submit_io_sync(dev, rqd);
>>  }
>>  +int pblk_submit_io_sync_sem(struct pblk *pblk, struct nvm_rq *rqd)
> 
> Nitpicking a bit. It looks to me that a function that has semaphore in its name, should take the semaphore in all cases unless it returns an error. When it only does it on writes, it creates confusion.
> 
> Maybe this would be one of the cases where it is okay to have the logic it in the caller function, or do such that it takes a flag if it should take the semaphore. That'll make it explicit when it is done.

I think it’s cleaner to make a helper as the pattern repeats on all write sync I/Os. I’m ok with moving the check to the caller and only using this helper on the write path. I can send a V3 next week. 

Javier.