Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752808AbdF0LX6 (ORCPT ); Tue, 27 Jun 2017 07:23:58 -0400 Received: from mx1.mpynet.fi ([82.197.21.84]:59511 "EHLO mx1.mpynet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbdF0LXw (ORCPT ); Tue, 27 Jun 2017 07:23:52 -0400 Date: Tue, 27 Jun 2017 14:23:44 +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: <20170627112344.GA52927@dhcp-216.srv.tuxera.com> References: <20170627104315.GA52146@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: 1290 Lines: 31 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.