From: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
To: linux-scsi@vger.kernel.org,
James Bottomley <jejb@linux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
"Manoj N. Kumar" <manoj@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org,
Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
Frederic Barrat <fbarrat@linux.vnet.ibm.com>,
Christophe Lombard <clombard@linux.vnet.ibm.com>
Subject: [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services
Date: Fri, 11 May 2018 14:05:22 -0500 [thread overview]
Message-ID: <1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com> (raw)
In-Reply-To: <1526065440-38806-1-git-send-email-ukrishn@linux.vnet.ibm.com>
When a superpipe process that makes use of virtual LUNs is terminated or
killed abruptly, there is a possibility that the cxlflash driver could
hang and deprive other operations on the adapter.
The release fop registered to be invoked on a context close, detaches
every LUN associated with the context. The underlying service to detach
the LUN assumes it has been called with the read semaphore held, and
releases the semaphore before any operation that could be time consuming.
When invoked without holding the read semaphore, an opportunity is created
for the semaphore's count to become negative when it is temporarily
released during one of these potential lengthy operations. This negative
count results in subsequent acquisition attempts taking forever, leading
to the hang.
To support the current design point of holding the semaphore on the
ioctl() paths, the release fop should acquire it before invoking any
ioctl services.
Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
drivers/scsi/cxlflash/superpipe.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/cxlflash/superpipe.c b/drivers/scsi/cxlflash/superpipe.c
index 04a3bf9..5ba6e62 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -988,6 +988,10 @@ static int cxlflash_disk_detach(struct scsi_device *sdev,
* theoretically never occur), every call into this routine results
* in a complete freeing of a context.
*
+ * Detaching the LUN is typically an ioctl() operation and the underlying
+ * code assumes that ioctl_rwsem has been acquired as a reader. To support
+ * that design point, the semaphore is acquired and released around detach.
+ *
* Return: 0 on success
*/
static int cxlflash_cxl_release(struct inode *inode, struct file *file)
@@ -1026,9 +1030,11 @@ static int cxlflash_cxl_release(struct inode *inode, struct file *file)
dev_dbg(dev, "%s: close for ctxid=%d\n", __func__, ctxid);
+ down_read(&cfg->ioctl_rwsem);
detach.context_id = ctxi->ctxid;
list_for_each_entry_safe(lun_access, t, &ctxi->luns, list)
_cxlflash_disk_detach(lun_access->sdev, ctxi, &detach);
+ up_read(&cfg->ioctl_rwsem);
out_release:
cfg->ops->fd_release(inode, file);
out:
--
2.1.0
next prev parent reply other threads:[~2018-05-11 19:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 19:04 [PATCH 0/7] Miscellaneous patches and bug fixes Uma Krishnan
2018-05-11 19:04 ` [PATCH 1/7] cxlflash: Yield to active send threads Uma Krishnan
2018-05-16 15:09 ` Matthew R. Ochs
2018-05-11 19:05 ` [PATCH 2/7] cxlflash: Limit the debug logs in the IO path Uma Krishnan
2018-05-16 15:53 ` Matthew R. Ochs
2018-05-11 19:05 ` Uma Krishnan [this message]
2018-05-16 15:54 ` [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services Matthew R. Ochs
2018-05-11 19:05 ` [PATCH 4/7] cxlflash: Use local mutex for AFU serialization Uma Krishnan
2018-05-11 19:05 ` [PATCH 5/7] cxlflash: Add include guards to backend.h Uma Krishnan
2018-05-16 15:58 ` Matthew R. Ochs
2018-05-11 19:06 ` [PATCH 6/7] cxlflash: Abstract hardware dependent assignments Uma Krishnan
2018-05-16 15:59 ` Matthew R. Ochs
2018-05-11 19:06 ` [PATCH 7/7] cxlflash: Isolate external module dependencies Uma Krishnan
2018-05-16 16:13 ` Matthew R. Ochs
2018-05-18 15:23 ` [PATCH 0/7] Miscellaneous patches and bug fixes Martin K. Petersen
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=1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com \
--to=ukrishn@linux.vnet.ibm.com \
--cc=andrew.donnellan@au1.ibm.com \
--cc=clombard@linux.vnet.ibm.com \
--cc=fbarrat@linux.vnet.ibm.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=manoj@linux.vnet.ibm.com \
--cc=martin.petersen@oracle.com \
--cc=mrochs@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).