Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock

On Wed, 2016-10-26 at 11:44 -0700, Bart Van Assche wrote: > The solution I prefer is to modify the SCSI scanning code such that > the scan_mutex is only held while performing the actual LUN scanning > and while ensuring that no SCSI device has been created yet for a > certain LUN number but not

[PATCH v5 14/14] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

Make nvme_requeue_req() check BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED. Remove the QUEUE_FLAG_STOPPED manipulations that became superfluous because of this change. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). This patch fixes a race condition: using

[PATCH v5 12/14] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

Ensure that if scsi-mq is enabled that scsi_internal_device_block() waits until ongoing shost->hostt->queuecommand() calls have finished. Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Martin K. Petersen

[PATCH v5 10/14] dm: Fix a race condition related to stopping and starting queues

Ensure that all ongoing dm_mq_queue_rq() and dm_mq_requeue_request() calls have stopped before setting the "queue stopped" flag. This allows to remove the "queue stopped" test from dm_mq_queue_rq() and dm_mq_requeue_request(). This patch fixes a race condition because dm_mq_queue_rq() is called

[PATCH v5 11/14] SRP transport: Move queuecommand() wait code to SCSI core

Additionally, rename srp_wait_for_queuecommand() into scsi_wait_for_queuecommand() and add a comment about the queuecommand() call from scsi_send_eh_cmnd(). Signed-off-by: Bart Van Assche Cc: James Bottomley Cc: Martin K. Petersen

[PATCH v5 09/14] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED in the dm start and stop queue functions, only manipulate the latter flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). Signed-off-by: Bart Van Assche Acked-by: Mike Snitzer

[PATCH v5 07/14] blk-mq: Introduce blk_mq_quiesce_queue()

blk_mq_quiesce_queue() waits until ongoing .queue_rq() invocations have finished. This function does *not* wait until all outstanding requests have finished (this means invocation of request.end_io()). The algorithm used by blk_mq_quiesce_queue() is as follows: * Hold either an RCU read lock or an

[PATCH v5 08/14] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls are followed by kicking the requeue list. Hence add an argument to these two functions that allows to kick the requeue list. This was proposed by Christoph Hellwig. Signed-off-by: Bart Van Assche

[PATCH v5 05/14] blk-mq: Avoid that requeueing starts stopped queues

Since blk_mq_requeue_work() starts stopped queues and since execution of this function can be scheduled after a queue has been stopped it is not possible to stop queues without using an additional state variable to track whether or not the queue has been stopped. Hence modify blk_mq_requeue_work()

[PATCH v5 06/14] blk-mq: Remove blk_mq_cancel_requeue_work()

Since blk_mq_requeue_work() no longer restarts stopped queues canceling requeue work is no longer needed to prevent that a stopped queue would be restarted. Hence remove this function. Signed-off-by: Bart Van Assche Cc: Mike Snitzer Cc: Keith

[PATCH v5 04/14] blk-mq: Move more code into blk_mq_direct_issue_request()

Move the "hctx stopped" test and the insert request calls into blk_mq_direct_issue_request(). Rename that function into blk_mq_try_issue_directly() to reflect its new semantics. Pass the hctx pointer to that function instead of looking it up a second time. These changes avoid that code has to be

[PATCH v5 0/14] Fix race conditions related to stopping block layer queues

Hello Jens, Multiple block drivers need the functionality to stop a request queue and to wait until all ongoing request_fn() / queue_rq() calls have finished without waiting until all outstanding requests have finished. Hence this patch series that introduces the blk_mq_quiesce_queue()

[PATCH v5 01/14] blk-mq: Do not invoke .queue_rq() for a stopped queue

The meaning of the BLK_MQ_S_STOPPED flag is "do not call .queue_rq()". Hence modify blk_mq_make_request() such that requests are queued instead of issued if a queue has been stopped. Reported-by: Ming Lei Signed-off-by: Bart Van Assche

[PATCH v5 03/14] blk-mq: Introduce blk_mq_queue_stopped()

The function blk_queue_stopped() allows to test whether or not a traditional request queue has been stopped. Introduce a helper function that allows block drivers to query easily whether or not one or more hardware contexts of a blk-mq queue have been stopped. Signed-off-by: Bart Van Assche

[PATCH v5 02/14] blk-mq: Introduce blk_mq_hctx_stopped()

Multiple functions test the BLK_MQ_S_STOPPED bit so introduce a helper function that performs this test. Signed-off-by: Bart Van Assche Reviewed-by: Ming Lei Reviewed-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn

Re: [PATCH] Avoid that SCSI device removal through sysfs triggers a deadlock

On Thu, Oct 27, 2016 at 08:38:03AM -0700, Bart Van Assche wrote: > On 10/27/2016 02:46 AM, Johannes Thumshirn wrote: > > On Wed, Oct 26, 2016 at 11:44:51AM -0700, Bart Van Assche wrote: > > > +static void scsi_remove_device_async(struct scsi_device *sdev) > > > +{ > > > + if (scsi_device_get(sdev)

[Bug 172841] aacraid does not support TRIM in Raw (Pass Through) devices

https://bugzilla.kernel.org/show_bug.cgi?id=172841 --- Comment #2 from Badalyan Vyacheslav --- Long. I sold and took a LSI -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe

[Bug 172831] Adaptec ASR7805 in RAID (Expose RAW) mode recreate block devices and broke MDRAID

https://bugzilla.kernel.org/show_bug.cgi?id=172831 --- Comment #10 from Badalyan Vyacheslav --- Long. I sold and took a LSI -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe

Re: esp_scsi QTAG in FAS216

On Sun, 13 Apr 2014, David Miller wrote: > > esp_get_revision but later cleared in the same function. It appears > > we'd need to set it after the call to scsi_esp_register() - can you > > test whether that obsoletes the zorro_esp_slave_configure hack, > > Tuomas? > ... > > > Group 2

Re: [PATCH 11/12] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On Fri, Oct 28, 2016 at 11:51:35AM -0700, Bart Van Assche wrote: > I think it is wrong that kicking the requeue list starts stopped queues > because this makes it impossible to stop request processing without setting > an additional flag next to BLK_MQ_S_STOPPED. Can you have a look at the >

Re: [PATCH 11/12] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On 10/28/2016 08:51 AM, Keith Busch wrote: On Wed, Oct 26, 2016 at 03:56:04PM -0700, Bart Van Assche wrote: diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 7bb73ba..b662416 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -205,7 +205,7 @@ void

Re: [PATCH] vmw_pvscsi: return SUCCESS for successful command aborts

On Fri, 2016-10-28 at 12:27 -0400, David Jeffery wrote: > The vmw_pvscsi driver reports most successful aborts as FAILED to the scsi > error handler. This is do to a misunderstanding of how completion_done() > works > and its interaction with a successful wait using >

Re: [PATCH] vmw_pvscsi: return SUCCESS for successful command aborts

- Original Message - > From: "David Jeffery" > To: linux-scsi@vger.kernel.org > Sent: Friday, October 28, 2016 12:27:26 PM > Subject: [PATCH] vmw_pvscsi: return SUCCESS for successful command aborts > > > The vmw_pvscsi driver reports most successful aborts as

Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

> On 10/28/2016 01:31 PM, Hannes Reinecke wrote: > > On 10/28/2016 11:53 AM, Steffen Maier wrote: > >> On 10/13/2016 06:24 PM, Johannes Thumshirn wrote: > >>> On Thu, Oct 13, 2016 at 05:15:25PM +0200, Steffen Maier wrote: ... > fc_bsg_request_handler() > req->errors =

[PATCH] vmw_pvscsi: return SUCCESS for successful command aborts

The vmw_pvscsi driver reports most successful aborts as FAILED to the scsi error handler. This is do to a misunderstanding of how completion_done() works and its interaction with a successful wait using wait_for_completion_timeout(). The vmw_pvscsi driver is expecting completion_done() to always

Re: [PATCH 11/12] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On Wed, Oct 26, 2016 at 03:56:04PM -0700, Bart Van Assche wrote: > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > index 7bb73ba..b662416 100644 > --- a/drivers/nvme/host/core.c > +++ b/drivers/nvme/host/core.c > @@ -205,7 +205,7 @@ void nvme_requeue_req(struct request *req) >

Re: [PATCH] scsi_dh_alua: fix wrong scsi_device_put() in alua_rtpg_queue()

On 10/28/2016 01:21 AM, tang.jun...@zte.com.cn wrote: > From: "tang.junhui" > > scsi_device_put() is called when the conditions pg->rtpg_sdev!=NULL > and queue_delayed_work() failure satisfied, actually it should be not > to call because scsi_device_get() is not called

Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On 10/28/2016 01:31 PM, Hannes Reinecke wrote: On 10/28/2016 11:53 AM, Steffen Maier wrote: On 10/13/2016 06:24 PM, Johannes Thumshirn wrote: On Thu, Oct 13, 2016 at 05:15:25PM +0200, Steffen Maier wrote: I'm puzzled. $ git bisect start fc_bsg master

Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On 10/28/2016 11:53 AM, Steffen Maier wrote: > > > On 10/13/2016 06:24 PM, Johannes Thumshirn wrote: >> On Thu, Oct 13, 2016 at 05:15:25PM +0200, Steffen Maier wrote: >>> I'm puzzled. >>> >>> $ git bisect start fc_bsg master > 3087864ce3d7282f59021245d8a5f83ef1caef18 is the first bad

Re: [PATCH v2 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On 10/13/2016 06:24 PM, Johannes Thumshirn wrote: On Thu, Oct 13, 2016 at 05:15:25PM +0200, Steffen Maier wrote: I'm puzzled. $ git bisect start fc_bsg master 3087864ce3d7282f59021245d8a5f83ef1caef18 is the first bad commit commit 3087864ce3d7282f59021245d8a5f83ef1caef18 Author: Johannes

Re: [PATCH] scsi_dh_alua: fix missing kref_put() in alua_rtpg_work()

On 10/28/2016 09:54 AM, tang.jun...@zte.com.cn wrote: > From: "tang.junhui" > > Reference count of pg leaks in alua_rtpg_work() since kref_put() > is not called to decrease the reference count of pg when the > condition pg->rtpg_sdev==NULL satisfied (actually it is easy

[PATCH] scsi_dh_alua: fix wrong scsi_device_put() in alua_rtpg_queue()

From: "tang.junhui" scsi_device_put() is called when the conditions pg->rtpg_sdev!=NULL and queue_delayed_work() failure satisfied, actually it should be not to call because scsi_device_get() is not called previous in this scene. Signed-off-by: tang.junhui

[PATCH] scsi_dh_alua: fix missing kref_put() in alua_rtpg_work()

From: "tang.junhui" Reference count of pg leaks in alua_rtpg_work() since kref_put() is not called to decrease the reference count of pg when the condition pg->rtpg_sdev==NULL satisfied (actually it is easy to satisfy), it would cause memory of pg leakage. Signed-off-by:

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On Thu, Oct 27, 2016 at 11:00:56AM +0200, Hannes Reinecke wrote: > BLOCK_PC is currently used indiscriminately for all non-filesystem > commands, ie for commands where the raw cdb is passed in via req->special. > > As such, is has a dual meaning: > - A pre-filled CDB > - do not evaluate the sense

Re: Crash in TCM-LIO

On Wed, 2016-10-26 at 09:01 +, Gurumurthy, Anil wrote: > Hello Nicholas, > > Thanks for confirming. The ABORT_TASK TMR_TASK_DOES_NOT_EXIST > exceptions here do not depend on the missing SCF_ACK_KREF bit > assignment. > > The earlier SCF_ACK_KREF reference leak fix is specific to TMR that

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

On 10/26/2016 8:08 AM, TomK wrote: On 10/26/2016 3:20 AM, Nicholas A. Bellinger wrote: Hello TomK & Co, Comments below. On Tue, 2016-10-25 at 22:05 -0400, TomK wrote: On 10/25/2016 1:28 AM, TomK wrote: On 10/24/2016 2:36 AM, Nicholas A. Bellinger wrote: Hi TomK, Thanks for reporting this