All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-nvme@lists.infradead.org, Jens Axboe <axboe@fb.com>,
	linux-block@vger.kernel.org,
	Bart Van Assche <bart.vanassche@sandisk.com>,
	Keith Busch <keith.busch@intel.com>,
	Sagi Grimberg <sagi@grimberg.me>, Yi Zhang <yi.zhang@redhat.com>,
	Johannes Thumshirn <jthumshirn@suse.de>
Subject: Re: [PATCH 6/6] nvme: remove .init_request callback
Date: Wed, 13 Dec 2017 14:43:09 +0800	[thread overview]
Message-ID: <20171213064151.GA1693@ming.t460p> (raw)
In-Reply-To: <20171212151032.GA15078@ming.t460p>

On Tue, Dec 12, 2017 at 11:10:32PM +0800, Ming Lei wrote:
> On Tue, Dec 12, 2017 at 03:13:58PM +0100, Christoph Hellwig wrote:
> > On Tue, Dec 12, 2017 at 07:02:32PM +0800, Ming Lei wrote:
> > > It may cause race by setting 'nvmeq' in nvme_init_request()
> > > because .init_request is called inside switching io scheduler, which
> > > may happen when the NVMe device is being resetted and its nvme queues
> > > are being freed and created. We don't have any sync between the two
> > > pathes.
> > > 
> > > This patch removes the .init_request callback and sets the nvmeq runtime,
> > > and fixes the following bug:
> > 
> > If ->init_request doesn't work for NVMe it won't work for any other
> > driver either, so we need to remove it entirely if we can't fix it.
> > 
> > I'd much rather try to fix it first, though.
> 
> Just checked all this uses, and it is a NVMe specific issue, because only
> NVMe's .init_request() associates reference of one variable to the request,
> and the variable itself may change during the request's lifetime.
> 
> And all the following .init_request() have this issue:
> 
> 	nvme_fc_init_request()
> 	nvme_rdma_init_request()
> 	nvme_loop_init_request()

After taking a close look, there isn't such issue actually on the above
three cases because the lifetime of ctl->queues(and each element) are
same with 'nvme_ctr/nvme_rdma_ctrl/nvme_loop_ctrl'. Not like nvme-pci,
->queues(and each element) won't be reallocated.

So it is a nvme-pci specific issue.

Thanks,
Ming

WARNING: multiple messages have this Message-ID (diff)
From: ming.lei@redhat.com (Ming Lei)
Subject: [PATCH 6/6] nvme: remove .init_request callback
Date: Wed, 13 Dec 2017 14:43:09 +0800	[thread overview]
Message-ID: <20171213064151.GA1693@ming.t460p> (raw)
In-Reply-To: <20171212151032.GA15078@ming.t460p>

On Tue, Dec 12, 2017@11:10:32PM +0800, Ming Lei wrote:
> On Tue, Dec 12, 2017@03:13:58PM +0100, Christoph Hellwig wrote:
> > On Tue, Dec 12, 2017@07:02:32PM +0800, Ming Lei wrote:
> > > It may cause race by setting 'nvmeq' in nvme_init_request()
> > > because .init_request is called inside switching io scheduler, which
> > > may happen when the NVMe device is being resetted and its nvme queues
> > > are being freed and created. We don't have any sync between the two
> > > pathes.
> > > 
> > > This patch removes the .init_request callback and sets the nvmeq runtime,
> > > and fixes the following bug:
> > 
> > If ->init_request doesn't work for NVMe it won't work for any other
> > driver either, so we need to remove it entirely if we can't fix it.
> > 
> > I'd much rather try to fix it first, though.
> 
> Just checked all this uses, and it is a NVMe specific issue, because only
> NVMe's .init_request() associates reference of one variable to the request,
> and the variable itself may change during the request's lifetime.
> 
> And all the following .init_request() have this issue:
> 
> 	nvme_fc_init_request()
> 	nvme_rdma_init_request()
> 	nvme_loop_init_request()

After taking a close look, there isn't such issue actually on the above
three cases because the lifetime of ctl->queues(and each element) are
same with 'nvme_ctr/nvme_rdma_ctrl/nvme_loop_ctrl'. Not like nvme-pci,
->queues(and each element) won't be reallocated.

So it is a nvme-pci specific issue.

Thanks,
Ming

  reply	other threads:[~2017-12-13  6:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 11:02 [PATCH 0/6] blk-mq: fix race related with device deletion/reset/switching sched Ming Lei
2017-12-12 11:02 ` Ming Lei
2017-12-12 11:02 ` [PATCH 1/6] blk-mq: quiesce queue before freeing queue Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 11:02 ` [PATCH 2/6] blk-mq: support concurrent blk_mq_quiesce_queue() Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 11:02 ` [PATCH 3/6] blk-mq: quiesce queue during switching io sched and updating nr_requests Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 11:02 ` [PATCH 4/6] blk-mq: avoid to map CPU into stale hw queue Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 14:12   ` Christoph Hellwig
2017-12-12 14:12     ` Christoph Hellwig
2017-12-12 15:12     ` Ming Lei
2017-12-12 15:12       ` Ming Lei
2017-12-12 11:02 ` [PATCH 5/6] blk-mq: fix race between updating nr_hw_queues and switching io sched Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 11:02 ` [PATCH 6/6] nvme: remove .init_request callback Ming Lei
2017-12-12 11:02   ` Ming Lei
2017-12-12 14:13   ` Christoph Hellwig
2017-12-12 14:13     ` Christoph Hellwig
2017-12-12 15:10     ` Ming Lei
2017-12-12 15:10       ` Ming Lei
2017-12-13  6:43       ` Ming Lei [this message]
2017-12-13  6:43         ` Ming Lei

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=20171213064151.GA1693@ming.t460p \
    --to=ming.lei@redhat.com \
    --cc=axboe@fb.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=hch@lst.de \
    --cc=jthumshirn@suse.de \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=yi.zhang@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.