Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755240AbcCaKHU (ORCPT ); Thu, 31 Mar 2016 06:07:20 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:33885 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbcCaKHQ (ORCPT ); Thu, 31 Mar 2016 06:07:16 -0400 Subject: Re: [PATCH 1/2] lightnvm: use rrpc->nr_luns to calculate the rrpc area size To: Wenwei Tao References: <1459348115-6072-1-git-send-email-ww.tao0320@gmail.com> <56FCE65D.8060901@lightnvm.io> Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: <56FCF6D0.7020009@lightnvm.io> Date: Thu, 31 Mar 2016 12:07:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1499 Lines: 39 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?