Re: [PATCH v2] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

On Thu, 03/30 11:30, Martin K. Petersen wrote: > Fam Zheng writes: > > >>rw_max = min_not_zero(logical_to_sectors(sdp, dev_max), > >> BLK_DEF_MAX_SECTORS); > > > > Yes, it is better. Is it okay to make the change when you apply? > > Sure.

Re: [PATCH 1/6] virtio: wrap find_vqs

On 2017年03月30日 22:32, Michael S. Tsirkin wrote: On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote: On 2017年03月30日 04:48, Michael S. Tsirkin wrote: We are going to add more parameters to find_vqs, let's wrap the call so we don't need to tweak all drivers every time. Signed-off-by:

[PATCH] tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case

From: Xiubo Li For the bidirectional case, the Data-Out buffer blocks will always at the head of the tcmu_cmd's bitmap, and before gathering the Data-In buffer, first of all it should skip the Data-Out ones, or the device supporting BIDI commands won't work. Fixed:

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

Mike Snitzer writes: Mike, > But while discussing this effort with Jeff Moyer he asked: shouldn't the > zeroed blocks be provisioned? This is a fairly embarassing question not > to be able to answer in the moment. So I clearly need to learn what the > overall intent of

Re: [PATCH 12/23] sd: handle REQ_UNMAP

"h...@lst.de" writes: > If you manually change the provisioning mode to WS10 on a device that > must use WRITE SAME (16) to be able to address all blocks you're already > screwed right now, and with this patch you can screw yourself through > the WRITE_ZEROES path in addition to the

commit 1b6ac5e3f "fnic: Using rport->dd_data to check rport online instead of rport_lookup."

Hi Satish, My customer hit below error when issue LIP to fnic controller: [94702.898408] sd 2:0:4:1: [sdx] tag#1 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [94702.898416] sd 2:0:4:1: [sdx] tag#1 CDB: Write(10) 2a 00 04 56 c0 08 00 00 08 00 [94702.898420] blk_update_request:

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30 2017 at 11:20am -0400, Martin K. Petersen wrote: > Mike Snitzer writes: > > > I can work on this now. Only question I have is: should DM thinp take > > care to zero any misaligned head and tail? (I assume so but with all > > the

[RFC 1/8] Introduce Peer-to-Peer memory (p2pmem) device

A p2pmem device is simply a PCI card with a BAR space that points to regular memory. This may be an independent PCI card or part of another completely unrelated device (like an IB card or a NVMe card). The p2pmem device is designed such that other drivers may register p2pmem memory for use by the

[RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

Now that we are using p2pmem SG buffers we occasionally have to copy to and from this memory. For this, we add an iomem flag to sg_copy_buffer for copying with iomemcpy. We also add the sg_iocopy_ variants to use this more easily. Signed-off-by: Logan Gunthorpe

[RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

p2pmem will always be iomem so if we ever access it, we should be using the correct methods to read and write to it. Signed-off-by: Logan Gunthorpe Signed-off-by: Stephen Bates Signed-off-by: Steve Wise ---

[RFC 8/8] p2pmem: Added char device user interface

This creates a userspace interface to use p2pmemory. A user can use mmap on the p2pmem char device to get buffers from the corresponding device. This allows a user to use p2p memory with existing interfaces like RDMA and O_DIRECT. This patch is a bit more controversial because people don't want

[RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

Hello, As discussed at LSF/MM we'd like to present our work to enable copy offload support in NVMe fabrics RDMA targets. We'd appreciate some review and feedback from the community on our direction. This series is not intended to go upstream at this point. The concept here is to use memory

[RFC 4/8] p2pmem: Add debugfs "stats" file

From: Steve Wise For each p2pmem instance, add a "stats" file to show the gen_pool statistics. Signed-off-by: Steve Wise Signed-off-by: Logan Gunthorpe Signed-off-by: Stephen Bates ---

[RFC 2/8] cxgb4: setup pcie memory window 4 and create p2pmem region

From: Steve Wise Some cxgb4 cards expose memory as part of BAR4. This patch registers this memory as a p2pmem device. Signed-off-by: Steve Wise Signed-off-by: Logan Gunthorpe Signed-off-by: Stephen Bates

[RFC 3/8] nvmet: Use p2pmem in nvme target

We create a configfs attribute in each nvme-fabrics target port to enable p2p memory use. When enabled, the port will only then use the p2p memory if a p2p memory device can be found which is behind the same switch as the RDMA port and all the block devices in use. If the user enabled it an no

[RFC 7/8] p2pmem: Support device removal

This patch creates a list of callbacks to notify users of this memory that the p2pmem device is going away or gone. In nvmet-rdma, we disconnect any queue using p2p memory. The remote side will then automatically reconnect in a couple seconds and regular system memory (or a different p2pmem

Re: [PATCH 12/23] sd: handle REQ_UNMAP

On Thu, Mar 30, 2017 at 11:28:32AM -0400, Martin K. Petersen wrote: > "h...@lst.de" writes: > > Christoph, > > > On Tue, Mar 28, 2017 at 04:48:55PM +, Bart Van Assche wrote: > >> > if (sdp->no_write_same) > >> > return BLKPREP_INVALID; > >> >

Re: [PATCH 23/23] block: remove the discard_zeroes_data flag

On Thu, Mar 30, 2017 at 11:29:29AM -0400, Martin K. Petersen wrote: > "h...@lst.de" writes: > > > Jens, any opinion? I'd like to remove it too, but I fear it might > > break things. We could deprecate it first with a warning when read > > and then remove it a few releases down the

[PATCH] osd_uld: Check scsi_device_get() return value

scsi_device_get() can fail. Hence check its return value. Signed-off-by: Bart Van Assche Cc: Boaz Harrosh --- drivers/scsi/osd/osd_uld.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/osd/osd_uld.c

Re: [PATCH 1/2] iscsi-target: Fix TMR reference leak during session shutdown

On Thu, 2017-03-30 at 08:29 +, Nicholas A. Bellinger wrote: > diff --git a/drivers/target/iscsi/iscsi_target_util.c > b/drivers/target/iscsi/iscsi_target_util.c > index 5041a9c..b464033 100644 > --- a/drivers/target/iscsi/iscsi_target_util.c > +++ b/drivers/target/iscsi/iscsi_target_util.c >

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Thu, Mar 30 2017 at 11:22am -0400, Martin K. Petersen wrote: > Mike Snitzer writes: > > > Would be very useful, particularly for testing, if > > drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES. > > There is no WRITE ZEROES in

Re: [PATCH] be2iscsi: switch to pci_alloc_irq_vectors

Christoph Hellwig writes: > Any progress on that? I'd like to get be2iscsi off the old MSI-X API > for 4.12. Applied to 4.12/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

Fam Zheng writes: >> rw_max = min_not_zero(logical_to_sectors(sdp, dev_max), >> BLK_DEF_MAX_SECTORS); > > Yes, it is better. Is it okay to make the change when you apply? Sure. Applied to 4.11/scsi-fixes. -- Martin K. Petersen Oracle

Re: [PATCH 23/23] block: remove the discard_zeroes_data flag

"h...@lst.de" writes: > Jens, any opinion? I'd like to remove it too, but I fear it might > break things. We could deprecate it first with a warning when read > and then remove it a few releases down the road. I know of several apps that check this variable (as opposed to the

Re: [PATCH 12/23] sd: handle REQ_UNMAP

"h...@lst.de" writes: Christoph, > On Tue, Mar 28, 2017 at 04:48:55PM +, Bart Van Assche wrote: >> >if (sdp->no_write_same) >> >return BLKPREP_INVALID; >> >if (sdkp->ws16 || sector > 0x || nr_sectors > 0x) >> >> Users can change the provisioning

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

Mike Snitzer writes: > Would be very useful, particularly for testing, if > drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES. There is no WRITE ZEROES in SCSI. You should be able to get the right behavior with lbpws=1 lbprz=1. -- Martin K. Petersen

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

Mike Snitzer writes: > I can work on this now. Only question I have is: should DM thinp take > care to zero any misaligned head and tail? (I assume so but with all > the back and forth between Bart, Paolo and Martin I figured I'd ask > explicitly). Yep, let's make sure our

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

Would be very useful, particularly for testing, if drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES.

Re: [PATCHv5 0/2] tcmu: For bugs fix only

On Thu, 2017-03-30 at 01:48 -0700, Nicholas A. Bellinger wrote: > Just for future reference, the flow of these tags should reflect the > history of the patch. Eg: > > Reviewed-by: First reviewer > Tested-by: First tester > Reviewed-by: Second reviewer

[PATCH] target/user: PGR Support

This adds PGR support for just TCMU, since tcmu doesn't have the necessary IT_NEXUS info to process PGR in userspace, so have those commands be processed in kernel. Signed-off-by: Bryant G. Ly --- drivers/target/target_core_configfs.c | 10 +-

Re: [PATCH 1/6] virtio: wrap find_vqs

On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote: > > > On 2017年03月30日 04:48, Michael S. Tsirkin wrote: > > We are going to add more parameters to find_vqs, let's wrap the call so > > we don't need to tweak all drivers every time. > > > > Signed-off-by: Michael S.

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30 2017 at 7:44am -0400, Christoph Hellwig wrote: > On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote: > > > Will it make an fstrim cause thinly provisioned > > devices to suddenly be fully allocated? > > Not for SCSI devices. Yes for dm-thinp until it

[PATCH 2/3] add test: generic/420 check information lead for lio-fileio

Signed-off-by: Dmitry Monakhov --- tests/generic/420 | 77 +++ tests/generic/420.out | 2 ++ tests/generic/group | 1 + 3 files changed, 80 insertions(+) create mode 100755 tests/generic/420 create mode 100644

[PATCH 1/3] add lio-target helpers

Linux-IO Target is very good framework for testing block backend. It is more flexible than scsi_debug. http://linux-iscsi.org/wiki/LIO Signed-off-by: Dmitry Monakhov --- common/config| 2 + common/liotarget | 111

[PATCH 3/3] add test: generic/421 basic blockdev T10-DIF-TYPE1 integrity checks

Test create virtual block device via lio-targed infastructure and perform basic IO operations with data corruption detection. Temprorally mark is as dangerous, because currently it trigger BUG_ON inside blkdev_issue_flush BTW: I use 'dd' to test read from corrupted image instead of xfs_io

[PATCH 0/3] Improve block device testing coverage

During LSFMM we have discussed how to test lower-backend of linux IO-stack. Common opinion was that xfstests is the most obvious solution which cover most of use cases filesystem care about. I'm working on integration T10-DIF/DIF data integrity features to ext4, for that reason we need to be

Re: [Drbd-dev] [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30, 2017 at 01:44:09PM +0200, Christoph Hellwig wrote: > On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote: > > On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote: > > > It seems like DRBD assumes its on the wire TRIM request always zeroes > > > data. > > >

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote: > On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote: > > It seems like DRBD assumes its on the wire TRIM request always zeroes data. > > Use that fact to implement REQ_OP_WRITE_ZEROES. > > > > XXX: will need a careful

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote: > It seems like DRBD assumes its on the wire TRIM request always zeroes data. > Use that fact to implement REQ_OP_WRITE_ZEROES. > > XXX: will need a careful audit from the drbd team! Thanks, this one looks ok to me. The real

Re: [PATCHv5 0/2] tcmu: For bugs fix only

On 2017年03月30日 16:48, Nicholas A. Bellinger wrote: Hi Xiubo & Co, On Mon, 2017-03-27 at 17:07 +0800, lixi...@cmss.chinamobile.com wrote: From: Xiubo Li Changed for V5: - This only includes #1 and #2. And for old #3, #4 are still reviewing. - #1, since the issue

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

Lars, can you please take a look a patch 22 and check if it's safe? That's the big thing I want to know before posting the next version of the series. If it's not safe I'd like to drop that patch.

RE: [PATCH] be2iscsi: switch to pci_alloc_irq_vectors

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Friday, January 13, 2017 10:00 PM > To: subbu.seethara...@broadcom.com; ketan.muka...@broadcom.com; > jitendra.bhiv...@broadcom.com; linux-scsi@vger.kernel.org > Subject: [PATCH] be2iscsi: switch to

Re: [PATCH 23/23] block: remove the discard_zeroes_data flag

On Tue, Mar 28, 2017 at 05:00:48PM +, Bart Van Assche wrote: > > It seems to me like the documentation in Documentation/ABI/testing/sysfs-block > and the above code are not in sync. I think the above code will cause reading > from the discard_zeroes_data attribute to return an empty string

Re: [PATCH 11/23] block_dev: use blkdev_issue_zerout for hole punches

On Tue, Mar 28, 2017 at 04:50:47PM +, Bart Van Assche wrote: > On Thu, 2017-03-23 at 10:33 -0400, Christoph Hellwig wrote: > > This gets us support for non-discard efficient write of zeroes (e.g. NVMe) > > and preparse for removing the discard_zeroes_data flag. > > Hello Christoph, > >

Re: [PATCH 12/23] sd: handle REQ_UNMAP

On Tue, Mar 28, 2017 at 04:48:55PM +, Bart Van Assche wrote: > > if (sdp->no_write_same) > > return BLKPREP_INVALID; > > if (sdkp->ws16 || sector > 0x || nr_sectors > 0x) > > Users can change the provisioning mode from user space from SD_LBP_WS16 into >

Re: [PATCH 01/23] block: renumber REQ_OP_WRITE_ZEROES

On Tue, Mar 28, 2017 at 04:12:46PM +, Bart Van Assche wrote: > Since REQ_OP_WRITE_ZEROES was introduced in kernel v4.10, do we need > "Cc: stable" and "Fixes: a6f0788ec2881" tags for this patch? No. This just works around the way scsi_setup_cmnd sets up the data direction. Before this

Re: [PATCHv5 0/2] tcmu: For bugs fix only

Hi Xiubo & Co, On Mon, 2017-03-27 at 17:07 +0800, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > Changed for V5: > - This only includes #1 and #2. And for old #3, #4 are still reviewing. > - #1, since the issue reported by Ilias is a separate new one, and

Re: [PATCH 1/7] ѕd: split sd_setup_discard_cmnd

On Tue, Mar 28, 2017 at 08:05:09AM -0600, ax...@kernel.dk wrote: > > Although I know this is an issue in the existing code and not something > > introduced by you: please consider using logical_to_sectors() instead of > > open-coding this function. Otherwise this patch looks fine to me. > > The

Re: [PATCH] be2iscsi: switch to pci_alloc_irq_vectors

On Mon, Jan 23, 2017 at 09:41:45AM +0530, Jitendra Bhivare wrote: > We will be taking this up along with some other changes in the same area. Any progress on that? I'd like to get be2iscsi off the old MSI-X API for 4.12.

[PATCH 2/2] target: Avoid mappedlun symlink creation during lun shutdown

From: Nicholas Bellinger This patch closes a race between se_lun deletion during configfs unlink in target_fabric_port_unlink() -> core_dev_del_lun() -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks waiting for percpu_ref RCU grace period to finish, but a new

[PATCH 1/2] iscsi-target: Fix TMR reference leak during session shutdown

From: Nicholas Bellinger This patch fixes a iscsi-target specific TMR reference leak during session shutdown, that could occur when a TMR was quiesced before the hand-off back to iscsi-target code via transport_cmd_check_stop_to_fabric(). The reference leak happens because

[PATCH 0/2] target: Bug-fixes for v4.11-rc

From: Nicholas Bellinger Hi all, Here are two additional target bug-fixes that have been found by the DATERA Q/A + automation team during extended longevity and stress testing atop v4.1.y stable code. The first is a iscsi-target specific TMR reference leak during session

Re: [PATCH v2] scsi/bfa: use designated initializers

On Wed, Mar 29, 2017 at 01:55:09PM -0700, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from

Re: [REGRESSION][Stable][v3.12.y][v4.4.y][v4.9.y][v4.10.y][v4.11-rc1] scsi: storvsc: properly set residual data length on errors

On Tue, Mar 28, 2017 at 04:14:09PM +, Stephen Hemminger wrote: > I decided not to send it to stable since problem was only observed on > 4.11 but it is probably endemic to all GEN2 VM's So, what does this mean? What should stable@ do? Nothing? Ok, now dropped this from my patch queue :)

Re: [PATCH 1/6] virtio: wrap find_vqs

On Wed, 29 Mar 2017 23:48:44 +0300 "Michael S. Tsirkin" wrote: > We are going to add more parameters to find_vqs, let's wrap the call so > we don't need to tweak all drivers every time. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/block/virtio_blk.c

Re: [PATCH 1/6] virtio: wrap find_vqs

On 2017年03月30日 04:48, Michael S. Tsirkin wrote: We are going to add more parameters to find_vqs, let's wrap the call so we don't need to tweak all drivers every time. Signed-off-by: Michael S. Tsirkin --- A quick glance and it looks ok, but what the benefit of this series,