Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On 10/05/2016 03:49 PM, Ming Lei wrote: We can use srcu read lock for BLOCKING and rcu read lock for non-BLOCKING, by putting *_read_lock() and *_read_unlock() into two wrappers, which should minimize the cost of srcu read lock & unlock and the code is still easy to read & verify. Hello Ming,

Re: [PATCH v2 6/7] SRP transport: Port srp_wait_for_queuecommand() to scsi-mq

On 10/05/2016 10:38 AM, Sagi Grimberg wrote: +static void srp_mq_wait_for_queuecommand(struct Scsi_Host *shost) +{ +struct scsi_device *sdev; +struct request_queue *q; + +shost_for_each_device(sdev, shost) { +q = sdev->request_queue; + +blk_mq_quiesce_queue(q); +

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On Thu, Oct 6, 2016 at 5:08 AM, Bart Van Assche wrote: > On 10/05/2016 12:11 PM, Sagi Grimberg wrote: >> >> I was referring to weather we can take srcu in the submission path >> conditional of the hctx being STOPPED? > > > Hello Sagi, > > Regarding run-time overhead: >

[PATCH] scsi: ufshcd: fix possible unclocked register access

Vendor specific setup_clocks callback may require the clocks managed by ufshcd driver to be ON. So if the vendor specific setup_clocks callback is called while the required clocks are turned off, it could result into unclocked register access. To prevent possible unclock register access, this

[PATCH v2] scsi: ufshcd: fix possible unclocked register access

Vendor specific setup_clocks callback may require the clocks managed by ufshcd driver to be ON. So if the vendor specific setup_clocks callback is called while the required clocks are turned off, it could result into unclocked register access. To prevent possible unclock register access, this

[PATCH v7 2/7] blk-sysfs: Add 'chunk_sectors' to sysfs attributes

From: Hannes Reinecke The queue limits already have a 'chunk_sectors' setting, so we should be presenting it via sysfs. Signed-off-by: Hannes Reinecke [Damien: Updated Documentation/ABI/testing/sysfs-block] Signed-off-by: Damien Le Moal

[PATCH v7 3/7] block: update chunk_sectors in blk_stack_limits()

From: Hannes Reinecke Signed-off-by: Hannes Reinecke Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Shaun Tancheff

[PATCH v7 5/7] block: Implement support for zoned block devices

From: Hannes Reinecke Implement zoned block device zone information reporting and reset. Zone information are reported as struct blk_zone. This implementation does not differentiate between host-aware and host-managed device models and is valid for both. Two functions are provided:

[PATCH v7 6/7] sd: Implement support for ZBC devices

From: Hannes Reinecke Implement ZBC support functions to setup zoned disks, both host-managed and host-aware models. Only zoned disks that satisfy the following conditions are supported: 1) All zones are the same size, with the exception of an eventual last smaller runt zone. 2)

[PATCH v7 1/7] block: Add 'zoned' queue limit

Add the zoned queue limit to indicate the zoning model of a block device. Defined values are 0 (BLK_ZONED_NONE) for regular block devices, 1 (BLK_ZONED_HA) for host-aware zone block devices and 2 (BLK_ZONED_HM) for host-managed zone block devices. The standards defined drive managed model is not

[PATCH v7 7/7] blk-zoned: implement ioctls

From: Shaun Tancheff Adds the new BLKREPORTZONE and BLKRESETZONE ioctls for respectively obtaining the zone configuration of a zoned block device and resetting the write pointer of sequential zones of a zoned block device. The BLKREPORTZONE ioctl maps directly to a single

[PATCH v7 4/7] block: Define zoned block device operations

From: Shaun Tancheff Define REQ_OP_ZONE_REPORT and REQ_OP_ZONE_RESET for handling zones of host-managed and host-aware zoned block devices. With with these two new operations, the total number of operations defined reaches 8 and still fits with the 3 bits definition

[PATCH v7 0/7] ZBC / Zoned block device support

This series introduces support for zoned block devices. It integrates earlier submissions by Hannes Reinecke and Shaun Tancheff. Compared to the previous series version, the code was significantly simplified by limiting support to zoned devices satisfying the following conditions: 1) All zones of

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On Wed, Oct 5, 2016 at 10:46 PM, Bart Van Assche wrote: > On 10/04/16 21:32, Ming Lei wrote: >> >> On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche >> wrote: >>> >>> On 10/01/16 15:56, Ming Lei wrote: If we just call the

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 5 October 2016 at 16:04, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >>> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >>>

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >>

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On 10/04/16 21:32, Ming Lei wrote: On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche wrote: On 10/01/16 15:56, Ming Lei wrote: If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(), the above code needn't to be duplicated any more. Can you have

Re: [PATCH v2 6/7] SRP transport: Port srp_wait_for_queuecommand() to scsi-mq

+static void srp_mq_wait_for_queuecommand(struct Scsi_Host *shost) +{ + struct scsi_device *sdev; + struct request_queue *q; + + shost_for_each_device(sdev, shost) { + q = sdev->request_queue; + + blk_mq_quiesce_queue(q); +

Re: [PATCH] scsi: ufs: add support for BLKSECDISCARD

Hi SzymonX, On 2016-10-04 05:55, Mielczarek, SzymonX wrote: Hi Jadavani, _> Did you mean sending purge when bProvisioningType is set to 02h (TPRZ = 0)? why do we want to send the purge if TPRZ is 1?_ By doing Purge we want to protect from die level attacks (JESD220B 12.2.3.3). Once Erase is

Re: iscsi_trx going into D state

We are not able to identify the patch that you mentioned from Lee, can you give us a commit or a link to the patch? Thanks, Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Tue, Oct 4, 2016 at 5:46 AM, Christoph Hellwig

Re: [PATCH v2 7/7] [RFC] nvme: Fix a race condition

Avoid that nvme_queue_rq() is still running when nvme_stop_queues() returns. Untested. Signed-off-by: Bart Van Assche Cc: Keith Busch Cc: Christoph Hellwig Cc: Sagi Grimberg Bart this looks really good! and

Re: [PATCH v2 3/7] [RFC] 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. This patch fixes a race condition: using queue_flag_clear_unlocked() is not safe if any other function that manipulates the

Re: iscsi_trx going into D state

Thanks, we will apply that too. We'd like to get this stable. We'll report back on what we find with these patches. Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Wed, Oct 5, 2016 at 12:03 PM, Christoph Hellwig wrote: >

Re: [PATCH v2 1/7] blk-mq: Introduce blk_mq_queue_stopped()

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: iscsi_trx going into D state

Hi Robert, I actually got the name wrong, the patch wasn't from Lee, but from Zhu, another SuSE engineer. This is the one: http://www.spinics.net/lists/target-devel/msg13463.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

Hello Ming, Can you have a look at the attached patch? That patch uses an srcu read lock for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been set. Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like previous versions, this patch has been tested. Hey Bart,

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

Hello Ming, Can you have a look at the attached patch? That patch uses an srcu read lock for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been set. Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like previous versions, this patch has been tested. Hey Bart,

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On 10/05/2016 11:14 AM, Sagi Grimberg wrote: Hello Ming, Can you have a look at the attached patch? That patch uses an srcu read lock for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been set. Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like previous

Re: [PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

On Tuesday 04 October 2016 07:40:50 Finn Thain wrote: > This patch series has fixes for compatibility, reliability and > performance issues and some cleanup. It also includes a new version > of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. > > I've tested this patch series on a

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On 10/05/2016 12:11 PM, Sagi Grimberg wrote: I was referring to weather we can take srcu in the submission path conditional of the hctx being STOPPED? Hello Sagi, Regarding run-time overhead: * rcu_read_lock() is a no-op on CONFIG_PREEMPT_NONE kernels and is translated into