All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>
To: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>,
	linux-scsi@vger.kernel.org,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Frederic Barrat <fbarrat@linux.vnet.ibm.com>,
	"Manoj N. Kumar" <manoj@linux.vnet.ibm.com>,
	Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
	linuxppc-dev@lists.ozlabs.org,
	Christophe Lombard <clombard@linux.vnet.ibm.com>
Subject: Re: [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services
Date: Wed, 16 May 2018 10:54:35 -0500	[thread overview]
Message-ID: <20180516155435.GC8754@p8tul1-build.aus.stglabs.ibm.com> (raw)
In-Reply-To: <1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com>

On Fri, May 11, 2018 at 02:05:22PM -0500, Uma Krishnan wrote:
> 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>

Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>

WARNING: multiple messages have this Message-ID (diff)
From: "Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>
To: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org,
	James Bottomley <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Manoj N. Kumar" <manoj@linux.vnet.ibm.com>,
	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: Re: [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services
Date: Wed, 16 May 2018 10:54:35 -0500	[thread overview]
Message-ID: <20180516155435.GC8754@p8tul1-build.aus.stglabs.ibm.com> (raw)
In-Reply-To: <1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com>

On Fri, May 11, 2018 at 02:05:22PM -0500, Uma Krishnan wrote:
> 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>

Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>

  reply	other threads:[~2018-05-16 15:54 UTC|newest]

Thread overview: 30+ 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 ` Uma Krishnan
2018-05-11 19:04 ` [PATCH 1/7] cxlflash: Yield to active send threads Uma Krishnan
2018-05-11 19:04   ` Uma Krishnan
2018-05-16 15:09   ` Matthew R. Ochs
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-11 19:05   ` Uma Krishnan
2018-05-16 15:53   ` Matthew R. Ochs
2018-05-16 15:53     ` Matthew R. Ochs
2018-05-11 19:05 ` [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services Uma Krishnan
2018-05-11 19:05   ` Uma Krishnan
2018-05-16 15:54   ` Matthew R. Ochs [this message]
2018-05-16 15:54     ` 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   ` Uma Krishnan
2018-05-11 19:05 ` [PATCH 5/7] cxlflash: Add include guards to backend.h Uma Krishnan
2018-05-11 19:05   ` Uma Krishnan
2018-05-16 15:58   ` Matthew R. Ochs
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-11 19:06   ` Uma Krishnan
2018-05-16 15:59   ` Matthew R. Ochs
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-11 19:06   ` Uma Krishnan
2018-05-16 16:13   ` Matthew R. Ochs
2018-05-16 16:13     ` Matthew R. Ochs
2018-05-18 15:23 ` [PATCH 0/7] Miscellaneous patches and bug fixes Martin K. Petersen
2018-05-18 15:23   ` 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=20180516155435.GC8754@p8tul1-build.aus.stglabs.ibm.com \
    --to=mrochs@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=ukrishn@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 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.