linux-kernel - Re: [PATCH 1/3] lightnvm: pblk: refactor metadata paths

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:   Wed, 29 Aug 2018 13:19:45 +0000
From:   Javier Gonzalez <javier@...xlabs.com>
To:     Matias Bjørling <mb@...htnvm.io>
CC:     Jens Axboe <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 1/3] lightnvm: pblk: refactor metadata paths


> On 29 Aug 2018, at 15.02, Matias Bjørling <mb@...htnvm.io> wrote:
> 
> On 08/29/2018 10:56 AM, Javier González wrote:
>> pblk maintains two different metadata paths for smeta and emeta, which
>> store metadata at the start of the line and at the end of the line,
>> respectively. Until now, these path has been common for writing and
>> retrieving metadata, however, as these paths diverge, the common code
>> becomes less clear and unnecessary complicated.
>> In preparation for further changes to the metadata write path, this
>> patch separates the write and read paths for smeta and emeta and
>> removes the synchronous emeta path as it not used anymore (emeta is
>> scheduled asynchronously to prevent jittering due to internal I/Os).
>> Signed-off-by: Javier González <javier@...xlabs.com>
>> ---
>>  drivers/lightnvm/pblk-core.c     | 338 ++++++++++++++++++---------------------
>>  drivers/lightnvm/pblk-gc.c       |   2 +-
>>  drivers/lightnvm/pblk-recovery.c |   4 +-
>>  drivers/lightnvm/pblk.h          |   4 +-
>>  4 files changed, 163 insertions(+), 185 deletions(-)
>> diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
>> index dbf037b2b32f..09160ec02c5f 100644
>> --- a/drivers/lightnvm/pblk-core.c
>> +++ b/drivers/lightnvm/pblk-core.c
>> @@ -661,12 +661,137 @@ u64 pblk_lookup_page(struct pblk *pblk, struct pblk_line *line)
>>  	return paddr;
>>  }
>>  -/*
>> - * Submit emeta to one LUN in the raid line at the time to avoid a deadlock when
>> - * taking the per LUN semaphore.
>> - */
>> -static int pblk_line_submit_emeta_io(struct pblk *pblk, struct pblk_line *line,
>> -				     void *emeta_buf, u64 paddr, int dir)
>> +u64 pblk_line_smeta_start(struct pblk *pblk, struct pblk_line *line)
>> +{
>> +	struct nvm_tgt_dev *dev = pblk->dev;
>> +	struct nvm_geo *geo = &dev->geo;
>> +	struct pblk_line_meta *lm = &pblk->lm;
>> +	int bit;
>> +
>> +	/* This usually only happens on bad lines */
>> +	bit = find_first_zero_bit(line->blk_bitmap, lm->blk_per_line);
>> +	if (bit >= lm->blk_per_line)
>> +		return -1;
>> +
>> +	return bit * geo->ws_opt;
>> +}
>> +
>> +int pblk_line_smeta_read(struct pblk *pblk, struct pblk_line *line)
>> +{
>> +	struct nvm_tgt_dev *dev = pblk->dev;
>> +	struct pblk_line_meta *lm = &pblk->lm;
>> +	struct bio *bio;
>> +	struct nvm_rq rqd;
>> +	u64 paddr = pblk_line_smeta_start(pblk, line);
>> +	int i, ret;
>> +
>> +	memset(&rqd, 0, sizeof(struct nvm_rq));
>> +
>> +	rqd.meta_list = nvm_dev_dma_alloc(dev->parent, GFP_KERNEL,
>> +							&rqd.dma_meta_list);
>> +	if (!rqd.meta_list)
>> +		return -ENOMEM;
>> +
>> +	rqd.ppa_list = rqd.meta_list + pblk_dma_meta_size;
>> +	rqd.dma_ppa_list = rqd.dma_meta_list + pblk_dma_meta_size;
> 
> If patch 2 is put first, then this is not needed.
> 

True... I will reorder with the changes on 2/3.


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)