Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: jianchao.w.wang@oracle.com (jianchao.wang)
Subject: [PATCH V2] nvme: free pre-allocated queue if create ioq goes wrong
Date: Thu, 18 Jan 2018 13:27:49 +0800	[thread overview]
Message-ID: <e402e9f4-b884-df4b-3841-445ea38142d2@oracle.com> (raw)
In-Reply-To: <CAA7jztd_Ewejj9DZJKeYRWPi6t-PKW3tB4SR7h+fBT_8ztv0aQ@mail.gmail.com>

Hi Minwoo 

On 01/17/2018 11:00 PM, Minwoo Im wrote:
> On Mon, Jan 15, 2018@11:00 AM, Keith Busch <keith.busch@intel.com> wrote:
>> Unless this is the very first pass at initialisation, I don't think we
>> can free queues until after blk_mq_update_nr_hw_queues since the hctx
>> could otherwise point to freed memory.
> 
> If not in the first initial step, if (_online_queues_ < 2) driver will
> kill queues and
> remove namespaces. I thought this "killing queue" will handle what you concerned
> about. If I misunderstand what it is, please let me know.
> Think of the following scenario:
nvme_reset_work
  -> nvme_setup_io_queues
    -> nvme_create_io_queues
      -> nvme_free_queues
  -> nvme_kill_queues
    -> blk_set_queue_dying   // just freeze the queue here, but will not wait to be drained.
                                not new requests come in, but maybe still residual requests in blk-mq queues.
    -> blk_mq_unquiesce_queue

the queues are _unquiesced_ here, then the residual requests will be queued
and go through nvme_queue_rq. Then the freed nvme_queue structure will be accessed.
:)

Thanks
Jianchao

> Otherwise if (_online_queues_ >= 2) which means that
> at least one or more IO queue is prepared, blk_mq_update_nr_hw_queues()
> will be triggered as you said.
> 
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=7WdAxUBeiTUTCy8v-7zXyr4qk7sx26ATvfo6QSTvZyQ&m=DkKtzCStCZ1WNuxsJ2wSR-xMZ6lJWOHwGIdXYLbzPYc&s=BO4fWOEqPAS4YnfcEoj8jFyeEH68XPsseHc6Fc4PpsQ&e=
> 

  reply	other threads:[~2018-01-18  5:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-14 21:00 [PATCH V2] nvme: free pre-allocated queue if create ioq goes wrong Minwoo Im
2018-01-15  2:00 ` Keith Busch
2018-01-17 13:07   ` Minwoo Im
2018-01-17 15:00   ` Minwoo Im
2018-01-18  5:27     ` jianchao.wang [this message]
2018-01-18 10:25       ` Minwoo Im
2018-01-18 11:31         ` Keith Busch
2018-01-18 22:52           ` Minwoo Im

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=e402e9f4-b884-df4b-3841-445ea38142d2@oracle.com \
    --to=jianchao.w.wang@oracle.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