linux-kernel - Re: [PATCH 1/4] lightnvm: add sync and close block I/O types

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 May 2016 12:08:40 +0200
From:	Matias Bjørling <mb@...htnvm.io>
To:	Javier González <jg@...htnvm.io>
Cc:	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH 1/4] lightnvm: add sync and close block I/O types

On 05/05/2016 11:38 AM, Javier González wrote:
>
>> On 05 May 2016, at 11:21, Matias Bjørling <mb@...htnvm.io> wrote:
>>
>> On 05/04/2016 05:31 PM, Javier González wrote:
>>> Within a target, I/O requests stem from different paths, which might vary
>>> in terms of the data structures being allocated, context, etc. This
>>> might impact how the request is treated, or how memory is freed once
>>> the bio is completed.
>>>
>>> Add two different types of I/Os: (i) NVM_IOTYPE_SYNC, which indicates
>>> that the I/O is synchronous; and  (ii) NVM_IOTYPE_CLOSE_BLK, which
>>> indicates that the I/O closes the block to which all the ppas on the
>>> request belong to.
>>>
>>> Signed-off-by: Javier González <javier@...xlabs.com>
>>> ---
>>>   include/linux/lightnvm.h | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
>>> index 29a6890..6c02209 100644
>>> --- a/include/linux/lightnvm.h
>>> +++ b/include/linux/lightnvm.h
>>> @@ -11,6 +11,8 @@ enum {
>>>
>>>   	NVM_IOTYPE_NONE = 0,
>>>   	NVM_IOTYPE_GC = 1,
>>> +	NVM_IOTYPE_SYNC = 2,
>>> +	NVM_IOTYPE_CLOSE_BLK = 4,
>>>   };
>>>
>>>   #define NVM_BLK_BITS (16)
>>
>> The sync should not be necessary when the read path is implemented
>> using bio_clone. Similarly for NVM_IOTYPE_CLOSE_BLK. The write
>> completion can be handled in the bio completion path.
>
> We need to know where the request comes from; we cannot do it just from
> having the bio. This is because we allocate different structures
> depending on the type of bio we send. It is not only which bio->end_io
> function we have, but which memory needs to be released. Sync is
> necessary for the read path when we have a partial bio (data both on
> write buffer and disk) that we need to fill up. Also for GC.. In this
> case, the bio is to be freed differently. In the case of close the case
> is similarly; we do not free memory on the end_io path, but on the caller.
>
> You can see how these flags are used on pblk. Maybe there is a better
> way of doing it that I could not see...
>

Use the bio completion path for both. For bio completion, free the data 
that is specific to the pblk flow and let the nvm_rq->end_io() 
completion path clean up the nvm_rq specific data. That will clean up 
the completion paths.

> Javier
>