linux-kernel - Re: [PATCH 1/2] lightnvm: use rrpc->nr_luns to calculate the rrpc area size

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]

Message-ID: <CACygaLDKuVvK0uH=iJ7d=JJGZtkzY10F=YQ-eJ64Xkk6M+EpyA@mail.gmail.com>
Date:	Thu, 31 Mar 2016 18:26:45 +0800
From:	Wenwei Tao <ww.tao0320@...il.com>
To:	Matias Bjørling <mb@...htnvm.io>
Cc:	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH 1/2] lightnvm: use rrpc->nr_luns to calculate the rrpc
 area size

This is okay with me.
By the way, why don't you like  (sector_t)dev->sec_size *
dev->sec_per_lun * rrpc->nr_luns, the change seems smaller?

2016-03-31 18:07 GMT+08:00 Matias Bjørling <mb@...htnvm.io>:
> On 03/31/2016 11:51 AM, Wenwei Tao wrote:
>>
>> This could be work, but it needs more steps when rrpc_area_init fails.
>> If rrpc_area_init fail we may come to rrpc_free and call
>> rrpc_area_free, we find and put the area by the rrpc->soffset value,
>> this value is zero when we fail to get an area, we may put an exist
>> area that really start from zero by mistake. If we move rrpc_area_init
>> call under the rrpc_luns_init call instead, we need a way to avoid it.
>
>
> Fair enough. How about this:
>
> diff --git i/drivers/lightnvm/rrpc.c w/drivers/lightnvm/rrpc.c
> index 3ab6495..05a0698 100644
> --- i/drivers/lightnvm/rrpc.c
> +++ w/drivers/lightnvm/rrpc.c
> @@ -1207,10 +1207,6 @@ static int rrpc_luns_init(struct rrpc *rrpc, int
> lun_begin, int lun_end)
>
>                 INIT_WORK(&rlun->ws_gc, rrpc_lun_gc);
>                 spin_lock_init(&rlun->lock);
> -
> -               rrpc->total_blocks += dev->blks_per_lun;
> -               rrpc->nr_sects += dev->sec_per_lun;
> -
>         }
>
>         return 0;
> @@ -1388,6 +1384,8 @@ static void *rrpc_init(struct nvm_dev *dev, struct
> gendisk *tdisk,
>         INIT_WORK(&rrpc->ws_requeue, rrpc_requeue);
>
>         rrpc->nr_luns = lun_end - lun_begin + 1;
> +       rrpc->total_blocks = dev->blks_per_lun * rrpc->nr_luns;
> +       rrpc->nr_sects = dev->sec_per_lun * rrpc->nr_luns;
>
>         /* simple round-robin strategy */
>         atomic_set(&rrpc->next_lun, -1);
>
> That nr_sects is initialized and we can use it in rrpc_area_init without
> moving the initialization order?