[PATCH 1/1] nvme: don't ignore tagset allocation failures

Keith Busch keith.busch at intel.com
Wed Mar 29 10:32:41 PDT 2017


On Wed, Mar 29, 2017 at 08:19:46PM +0300, Sagi Grimberg wrote:
> 
> > the nvme_dev_add() function silently ignores failures.
> > In case blk_mq_alloc_tag_set fails, we hit NULL deref while
> > calling blk_mq_init_queue during nvme_alloc_ns with tagset == NULL.
> > Instead, we'll not issue the scan_work in case tagset allocation
> > failed and leave the ctrl functional.
> > 
> > Signed-off-by: Max Gurtovoy <maxg at mellanox.com>
> > Reviewed-by: Keith Busch <keith.busch at intel.com>
> > ---
> >  drivers/nvme/host/core.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 9b3b57f..493722a 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -2115,9 +2115,9 @@ void nvme_queue_scan(struct nvme_ctrl *ctrl)
> >  {
> >  	/*
> >  	 * Do not queue new scan work when a controller is reset during
> > -	 * removal.
> > +	 * removal or if the tagset doesn't exist.
> >  	 */
> > -	if (ctrl->state == NVME_CTRL_LIVE)
> > +	if (ctrl->state == NVME_CTRL_LIVE && ctrl->tagset)
> >  		schedule_work(&ctrl->scan_work);
> 
> This looks wrong...
> 
> Why is the controller LIVE without a tagset allocated?
> I think you should handle it in the pci driver.

Not having a tagset doesn't mean we can't go live; it just means we can't
do IO, but the admin handle is still up for device management. Also,
nvme_queue_scan can be triggered from places outside nvme pci's control,
so I think Max's patch is an appropriate place to check.



More information about the Linux-nvme mailing list