linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rakesh Pandit <rakesh@tuxera.com>
To: Frans Klaver <fransklaver@gmail.com>
Cc: "Matias Bjørling" <m@bjorling.me>,
	axboe@fb.com, linux-block@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Matias Bjørling" <matias@cnexlabs.com>
Subject: Re: [PATCH] ligtnvm: if LUNs are already allocated fix return
Date: Tue, 27 Jun 2017 12:58:07 +0300	[thread overview]
Message-ID: <20170627095806.GA51634@dhcp-216.srv.tuxera.com> (raw)
In-Reply-To: <CAH6sp9NuonymjV0n2nsChcTKZ6sq5+S_s3uQ-48M0mY9LQh9mg@mail.gmail.com>

Hi Frans,

On Tue, Jun 27, 2017 at 11:06:44AM +0200, Frans Klaver wrote:
> On Tue, Jun 27, 2017 at 10:39 AM, Matias Bj�rling wrote:
> > From: Rakesh Pandit <rakesh@tuxera.com>
> >
> > 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 <rakesh@tuxera.com>
> > Signed-off-by: Matias Bj�rling <matias@cnexlabs.com>
> > ---
> >  drivers/lightnvm/core.c | 11 ++++++-----
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
> > index b8f82f5..9ff348f 100644
> > --- a/drivers/lightnvm/core.c
> > +++ b/drivers/lightnvm/core.c
> > @@ -235,7 +235,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct nvm_ioctl_create *create)
> >         struct nvm_target *t;
> >         struct nvm_tgt_dev *tgt_dev;
> >         void *targetdata;
> > -       int ret;
> > +       int ret = 0;
> 
> Is there any way that you can reach a 'return ret' without having ret
> set by some other assignment?
> 
>

No.

I should have been more careful.

> >         tt = nvm_find_target_type(create->tgttype, 1);
> >         if (!tt) {
> > @@ -252,8 +252,9 @@ 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;
> > +       ret = nvm_reserve_luns(dev, s->lun_begin, s->lun_end);
> > +       if (ret)
> > +               goto err;
> 
> Why don't you return err straight away here?

Intent was to future-proofing if num_reserve_luns would return
anything other than -EBUSY and 0 but yes returning -EBUSY directly
would be fine.

> 
> 
> >         t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
> >         if (!t) {
> > @@ -314,8 +315,8 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct nvm_ioctl_create *create)
> >         mutex_lock(&dev->mlock);
> >         list_add_tail(&t->list, &dev->targets);
> >         mutex_unlock(&dev->mlock);
> > -
> > -       return 0;
> > +err:
> > +       return ret;
> 
> This should not be necessary. In any case, the de-init order should
> always be the reverse of the init order, so we don't end up confused.

Only if we directly return -EBUSY.  Good point about getting confused
I would resend quickly by directly returning error.  That would not
confuse folks.

I would send an alternate patch which returns -EBUSY directly and do
same thing.

Thanks,

> 
> Frans

  reply	other threads:[~2017-06-27  9:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27  8:39 [PATCH] Small patch for 4.13 window Matias Bjørling
2017-06-27  8:39 ` [PATCH] ligtnvm: if LUNs are already allocated fix return Matias Bjørling
2017-06-27  9:06   ` Frans Klaver
2017-06-27  9:58     ` Rakesh Pandit [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-05-13 19:50 Rakesh Pandit
     [not found] ` <0BEA8552-A2D0-4B70-A9CF-98A019726FCC@cnexlabs.com>
2017-05-29  9:05   ` Rakesh Pandit
2017-05-30 13:24     ` Matias Bjørling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170627095806.GA51634@dhcp-216.srv.tuxera.com \
    --to=rakesh@tuxera.com \
    --cc=axboe@fb.com \
    --cc=fransklaver@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m@bjorling.me \
    --cc=matias@cnexlabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).