From: keith.busch@linux.intel.com (Keith Busch)
Subject: [PATCH] nvme/pci: Use async_schedule for initial reset work
Date: Thu, 3 May 2018 15:05:02 -0600 [thread overview]
Message-ID: <20180503210502.GP5938@localhost.localdomain> (raw)
In-Reply-To: <alpine.LRH.2.02.1805031614210.5215@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, May 03, 2018@04:45:22PM -0400, Mikulas Patocka wrote:
> Suppose this:
> task 1: nvme_probe
> task 1: calls async_schedule(nvme_async_probe), that queues the work for
> task 2
> task 1: exits (so the device is active from pci subsystem's point of view)
> task 3: the pci subsystem calls nvme_remove
> task 3: calls nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
> task 3: cancel_work_sync(&dev->ctrl.reset_work); (does nothing because the
> work item hasn't started yet)
> task 3: nvme_remove does all the remaining work
> task 3: frees the device
> task 3: exists nvme_remove
> task 2: (in the async domain) runs nvme_async_probe
> task 2: calls nvme_reset_ctrl_sync
> task 2: nvme_reset_ctrl
> task 2: calls nvme_change_ctrl_state and queue_work - on a structure that
> was already freed by nvme_remove
>
> This bug is rare - but it may happen if the user too quickly activates and
> deactivates the device by writing to sysfs.
Okay, I think I see your point. Pairing a nvme_get_ctrl with a
nvme_put_ctrl should fix that.
WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@linux.intel.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Sagi Grimberg <sagi@grimberg.me>,
Ming Lei <tom.leiming@gmail.com>,
linux-nvme <linux-nvme@lists.infradead.org>,
Keith Busch <keith.busch@intel.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] nvme/pci: Use async_schedule for initial reset work
Date: Thu, 3 May 2018 15:05:02 -0600 [thread overview]
Message-ID: <20180503210502.GP5938@localhost.localdomain> (raw)
In-Reply-To: <alpine.LRH.2.02.1805031614210.5215@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, May 03, 2018 at 04:45:22PM -0400, Mikulas Patocka wrote:
> Suppose this:
> task 1: nvme_probe
> task 1: calls async_schedule(nvme_async_probe), that queues the work for
> task 2
> task 1: exits (so the device is active from pci subsystem's point of view)
> task 3: the pci subsystem calls nvme_remove
> task 3: calls nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
> task 3: cancel_work_sync(&dev->ctrl.reset_work); (does nothing because the
> work item hasn't started yet)
> task 3: nvme_remove does all the remaining work
> task 3: frees the device
> task 3: exists nvme_remove
> task 2: (in the async domain) runs nvme_async_probe
> task 2: calls nvme_reset_ctrl_sync
> task 2: nvme_reset_ctrl
> task 2: calls nvme_change_ctrl_state and queue_work - on a structure that
> was already freed by nvme_remove
>
> This bug is rare - but it may happen if the user too quickly activates and
> deactivates the device by writing to sysfs.
Okay, I think I see your point. Pairing a nvme_get_ctrl with a
nvme_put_ctrl should fix that.
next prev parent reply other threads:[~2018-05-03 21:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 21:17 [PATCH] nvme/pci: Use async_schedule for initial reset work Keith Busch
2018-04-28 9:11 ` Ming Lei
2018-04-30 19:45 ` Keith Busch
2018-05-01 23:33 ` Mikulas Patocka
2018-05-02 15:29 ` Keith Busch
2018-05-03 14:55 ` Mikulas Patocka
2018-05-03 14:55 ` Mikulas Patocka
2018-05-03 20:15 ` Keith Busch
2018-05-03 20:15 ` Keith Busch
2018-05-03 20:45 ` Mikulas Patocka
2018-05-03 20:45 ` Mikulas Patocka
2018-05-03 21:05 ` Keith Busch [this message]
2018-05-03 21:05 ` Keith Busch
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=20180503210502.GP5938@localhost.localdomain \
--to=keith.busch@linux.intel.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.