From: Revanth Rajashekar <revanth.rajashekar@intel.com>
To: linux-nvme@lists.infradead.org, hch@lst.de
Cc: kbusch@kernel.org, damien.lemoal@wdc.com,
backports@vger.kernel.org,
Revanth Rajashekar <revanth.rajashekar@intel.com>
Subject: [PATCH 0/3] [backport] nvme: Consolidate chunk_sectors settings
Date: Mon, 21 Sep 2020 12:47:25 -0600 [thread overview]
Message-ID: <20200921184728.11291-1-revanth.rajashekar@intel.com> (raw)
Backport commit 38adf94e166e3cb4eb89683458ca578051e8218d and it's
dependencies to linux-stable 5.4.y.
Dependent commits:
314d48dd224897e35ddcaf5a1d7d133b5adddeb7
e08f2ae850929d40e66268ee47e443e7ea56eeb7
When running test cases to stress NVMe device, a race condition / deadlocks is
seen every couple of days or so where multiple threads are trying to acquire
ctrl->subsystem->lock or ctrl->scan_lock.
The test cases send a lot nvme-cli requests to do Sanitize, Format, FW Download,
FW Activate, Flush, Get Log, Identify, and reset requests to two controllers
that share a namespace. Some of those commands target a namespace, some target
a controller. The commands are sent in random order and random mix to the two
controllers.
The test cases does not wait for nvme-cli requests to finish before sending more.
So for example, there could be multiple reset requests, multiple format requests,
outstanding at the same time as a sanitize, on both paths at the same time, etc.
Many of these test cases include combos that don't really make sense in the
context of NVMe, however it is used to create as much stress as possible.
This patchset fixes this issue.
Similar issue with a detailed call trace/log was discussed in the LKML
Link: https://lore.kernel.org/linux-nvme/04580CD6-7652-459D-ABDD-732947B4A6DF@javigon.com/
Revanth Rajashekar (3):
nvme: Cleanup and rename nvme_block_nr()
nvme: Introduce nvme_lba_to_sect()
nvme: consolidate chunk_sectors settings
drivers/nvme/host/core.c | 40 +++++++++++++++++++---------------------
drivers/nvme/host/nvme.h | 16 +++++++++++++---
2 files changed, 32 insertions(+), 24 deletions(-)
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe backports" in
next reply other threads:[~2020-09-21 18:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 18:47 Revanth Rajashekar [this message]
2020-09-21 18:47 ` [PATCH 1/3] [backport] nvme: Cleanup and rename nvme_block_nr() Revanth Rajashekar
2020-09-21 18:47 ` [PATCH 2/3] [backport] nvme: Introduce nvme_lba_to_sect() Revanth Rajashekar
2020-09-21 18:47 ` [PATCH 3/3] [backport] nvme: consolidate chunk_sectors settings Revanth Rajashekar
2020-09-21 19:25 ` [PATCH 0/3] [backport] nvme: Consolidate " Johannes Berg
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=20200921184728.11291-1-revanth.rajashekar@intel.com \
--to=revanth.rajashekar@intel.com \
--cc=backports@vger.kernel.org \
--cc=damien.lemoal@wdc.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).