Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755366AbcCaK0r (ORCPT ); Thu, 31 Mar 2016 06:26:47 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:34985 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752206AbcCaK0q convert rfc822-to-8bit (ORCPT ); Thu, 31 Mar 2016 06:26:46 -0400 MIME-Version: 1.0 In-Reply-To: <56FCF6D0.7020009@lightnvm.io> References: <1459348115-6072-1-git-send-email-ww.tao0320@gmail.com> <56FCE65D.8060901@lightnvm.io> <56FCF6D0.7020009@lightnvm.io> Date: Thu, 31 Mar 2016 18:26:45 +0800 Message-ID: Subject: Re: [PATCH 1/2] lightnvm: use rrpc->nr_luns to calculate the rrpc area size From: Wenwei Tao To: =?UTF-8?Q?Matias_Bj=C3=B8rling?= Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1761 Lines: 46 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 : > 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?