Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752759AbdF0LjS (ORCPT ); Tue, 27 Jun 2017 07:39:18 -0400 Received: from mx1.mpynet.fi ([82.197.21.84]:61156 "EHLO mx1.mpynet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751453AbdF0LjL (ORCPT ); Tue, 27 Jun 2017 07:39:11 -0400 Date: Tue, 27 Jun 2017 14:39:08 +0300 From: Rakesh Pandit To: Frans Klaver CC: Jens Axboe , Matias =?iso-8859-1?Q?Bj=F8rling?= , , "linux-kernel@vger.kernel.org" , Matias =?iso-8859-1?Q?Bj=F8rling?= , Javier =?iso-8859-1?Q?Gonz=E1lez?= Subject: Re: [PATCH V2] lightnvm: if LUNs are already allocated fix return Message-ID: <20170627113908.GA52999@dhcp-216.srv.tuxera.com> References: <20170627104315.GA52146@dhcp-216.srv.tuxera.com> <20170627112344.GA52927@dhcp-216.srv.tuxera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-ClientProxiedBy: tuxera-exch.ad.tuxera.com (10.20.48.11) To tuxera-exch.ad.tuxera.com (10.20.48.11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1925 Lines: 44 On Tue, Jun 27, 2017 at 01:27:40PM +0200, Frans Klaver wrote: > On Tue, Jun 27, 2017 at 1:23 PM, Rakesh Pandit wrote: > > On Tue, Jun 27, 2017 at 01:01:22PM +0200, Frans Klaver wrote: > >> On Tue, Jun 27, 2017 at 12:43 PM, Rakesh Pandit wrote: > >> > While creating new device with NVM_DEV_CREATE if LUNs are already > >> > allocated ioctl would return -ENOMEM which is wrong. This patch > >> > propagates -EBUSY from nvm_reserve_luns which is correct response. > >> > > >> > Fixes: ade69e243 ("lightnvm: merge gennvm with core") > >> > Signed-off-by: Rakesh Pandit > >> > --- > >> > > >> > V2: return error code directly instead of using ret variable (Frans) > >> > > >> > drivers/lightnvm/core.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c > >> > index b8f82f5..c5d71c6 100644 > >> > --- a/drivers/lightnvm/core.c > >> > +++ b/drivers/lightnvm/core.c > >> > @@ -253,7 +253,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct nvm_ioctl_create *create) > >> > mutex_unlock(&dev->mlock); > >> > > >> > if (nvm_reserve_luns(dev, s->lun_begin, s->lun_end)) > >> > - return -ENOMEM; > >> > + return -EBUSY; > >> > >> Why aren't you propagating ret in this version? > > > > Well nvm_reserve_luns either returns 0 or -EBUSY and it is unlikely > > that return value would change and even if it does this can be > > updated. > > If you propagate the result of nvm_reserve_luns(), the casual reader > will immediately understand that any possible faulty result is > returned. returning -EBUSY here might suggest you're overriding > whatever this function returns. I don't have a strong opinion for or against. That was being done irrespective of this change already. But you have a valid argument. I would post V3. Thanks,