[PATCH] virtio_scsi: Always try to read VPD pages

Passed through SCSI targets may have transfer limits which come from the host SCSI controller something on the host side other than the target itself. To make this work properly, the hypervisor can adjust the target's VPD information to advertise these limits. But for that to work, the guest has

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On Wed, Apr 12, 2017 at 06:38:07PM +, Bart Van Assche wrote: > On Wed, 2017-04-12 at 11:42 +0800, Ming Lei wrote: > > On Tue, Apr 11, 2017 at 06:18:36PM +, Bart Van Assche wrote: > > > On Tue, 2017-04-11 at 14:03 -0400, Mike Snitzer wrote: > > > > Rather than working so hard to use DM code

Re: [PATCH v2 3/4] sd: Make synchronize cache upon shutdown asynchronous

On Wed, 2017-04-12 at 16:41 +0200, Benjamin Block wrote: > On Mon, Apr 10, 2017 at 10:54:01AM -0700, Bart Van Assche wrote: > > [ ... ] > OK, so I take it the problem is when the queue is stopped, then the > completion in blk_execute_rq() will never be triggered and then we wait > for a timeout

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

On Thu, Mar 30, 2017 at 1:18 AM, Christoph Hellwig wrote: > 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 >>

Re: problem with discard granularity in sd

Hi Martin, I have identified the key difference between the older working kernels and newer ones; on older kernels the provisioning_mode is set to 'unmap', while on newer kernels it is 'writesame_16'. This is due to a change in sd_read_block_limits which prevents selection of SD_LBP_UNMAP if the

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

On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

[PATCH 16/17] cxlflash: Add hardware queues attribute

From: "Matthew R. Ochs" As staging for supporting multiple hardware queues, add an attribute to show and set the current number of hardware queues for the host. Support specifying a hard limit or a CPU affinitized value. This will allow the number of hardware queues to

[PATCH 17/17] cxlflash: Introduce hardware queue steering

From: "Matthew R. Ochs" As an enhancement to distribute requests to multiple hardware queues, add the infrastructure to hash a SCSI command into a particular hardware queue. Support the following scenarios when deriving which queue to use: single queue, tagging when

[PATCH 14/17] cxlflash: Improve asynchronous interrupt processing

From: "Matthew R. Ochs" The method used to decode asynchronous interrupts involves unnecessary loops to match up bits that are set with corresponding entries in the asynchronous interrupt information table. This algorithm is wasteful and does not scale well as new

[PATCH 15/17] cxlflash: Support multiple hardware queues

Introduce multiple hardware queues to improve legacy I/O path performance. Each hardware queue is comprised of a master context and associated I/O resources. The hardware queues are initially implemented as a static array embedded in the AFU. This will be transitioned to a dynamic allocation in a

[PATCH 13/17] cxlflash: Fix warnings/errors

From: "Matthew R. Ochs" As a general cleanup, address all reasonable checkpatch warnings and errors. These include enforcement of comment styles and including named identifiers in function prototypes. Signed-off-by: Matthew R. Ochs

[PATCH 11/17] cxlflash: Remove unnecessary DMA mapping

From: "Matthew R. Ochs" Devices supported by the cxlflash driver are fully coherent and do not require a bus address mapping. Avoid unnecessary path length by using the virtual address and length already present in the scatter-gather entry. Signed-off-by: Matthew R.

[PATCH 12/17] cxlflash: Fix power-of-two validations

From: "Matthew R. Ochs" Validation statements to enforce assumptions about specific defines are not being evaluated by the compiler due to the fact that they reside in a routine that is not used. To activate them, call the routine as part of module initialization. As

[PATCH 09/17] cxlflash: Support up to 4 ports

From: "Matthew R. Ochs" Update the driver to allow for future cards with 4 ports. Signed-off-by: Matthew R. Ochs Signed-off-by: Uma Krishnan --- drivers/scsi/cxlflash/main.c| 78

[PATCH 10/17] cxlflash: Fence EEH during probe

From: "Matthew R. Ochs" An EEH during probe can lead to a crash as the recovery thread races with the probe thread. To avoid this issue, introduce new states to fence out EEH recovery until probe has completed. Also ensure the reset wait queue is flushed during device

[PATCH 07/17] cxlflash: Hide FC internals behind common access routine

From: "Matthew R. Ochs" As staging to support FC-related updates to the SISlite specification, introduce helper routines to obtain references to FC resources that exist within the global map. This will allow changes to the underlying global map structure without

[PATCH 08/17] cxlflash: SISlite updates to support 4 ports

From: "Matthew R. Ochs" Update the SISlite header to support 4 ports as outlined in the SISlite specification. Address fallout from structure renames and refreshed organization throughout the driver. Determine the number of ports supported by a card from the global

[PATCH 05/17] cxlflash: Support dynamic number of FC ports

From: "Matthew R. Ochs" Transition from a static number of FC ports to a value that is derived during probe. For now, a static value is used but this will later be based on the type of card being configured. Signed-off-by: Matthew R. Ochs

[PATCH 06/17] cxlflash: Remove port configuration assumptions

From: "Matthew R. Ochs" At present, the cxlflash driver only supports hardware with two FC ports. The code was initially designed with this assumption and is dependent on having two FC ports - adding more ports will break logic within the driver. To mitigate this

[PATCH 02/17] cxlflash: Serialize RRQ access and support offlevel processing

From: "Matthew R. Ochs" As further staging to support processing the HRRQ by other means, access to the HRRQ needs to be serialized by a disabled lock. This will allow safe access in other non-hardware interrupt contexts. In an effort to minimize the period where

[PATCH 04/17] cxlflash: Update sysfs helper routines to pass config structure

From: "Matthew R. Ochs" As staging for future function, pass the config pointer instead of the AFU pointer for port-related sysfs helper routines. Signed-off-by: Matthew R. Ochs Signed-off-by: Uma Krishnan ---

[PATCH 03/17] cxlflash: Implement IRQ polling for RRQ processing

From: "Matthew R. Ochs" Currently, RRQ processing takes place on hardware interrupt context. This can be a heavy burden in some environments due to the overhead encountered while completing RRQ entries. In an effort to improve system performance, use the IRQ polling

[PATCH 01/17] cxlflash: Separate RRQ processing from the RRQ interrupt handler

From: "Matthew R. Ochs" In order to support processing the HRRQ by other means (e.g. polling), the processing portion of the current RRQ interrupt handler needs to be broken out into a separate routine. This will allow RRQ processing from places other than the RRQ

[PATCH 00/17] cxlflash: Enhancements and miscellaneous fixes

This patch series contains miscellaneous patches and adds 4 port device support. This series also includes patches to improve performance of the driver in the legacy IO path. This series is intended for 4.12 and is bisectable Matthew R. Ochs (16): cxlflash: Separate RRQ processing from the RRQ

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On Wed, 2017-04-12 at 11:42 +0800, Ming Lei wrote: > On Tue, Apr 11, 2017 at 06:18:36PM +, Bart Van Assche wrote: > > On Tue, 2017-04-11 at 14:03 -0400, Mike Snitzer wrote: > > > Rather than working so hard to use DM code against me, your argument > > > should be: "blk-mq drivers X, Y and Z

Re: [PATCH v4 0/6] Avoid that scsi-mq and dm-mq queue processing stalls sporadically

On Wed, 2017-04-12 at 12:55 +0200, Benjamin Block wrote: > On Fri, Apr 07, 2017 at 11:16:48AM -0700, Bart Van Assche wrote: > > The six patches in this patch series fix the queue lockup I reported > > recently on the linux-block mailing list. Please consider these patches > > for inclusion in the

Re: linux-next: manual merge of the scsi-mkp tree with the char-misc tree

On Tue, 2017-04-11 at 21:00 -0400, Martin K. Petersen wrote: > Bart Van Assche writes: > > Sorry that I had not yet noticed Logan's patch series. Should my two > > patches that conflict with Logan's patch series be dropped and > > reworked after Logan's patches are

[v2 PATCH for-4.4 15/16] blk-mq: Avoid memory reclaim when remapping queues

From: Gabriel Krisman Bertazi [ Upstream commit 36e1f3d107867b25c616c2fd294f5a1c9d4e5d09 ] While stressing memory and IO at the same time we changed SMT settings, we were able to consistently trigger deadlocks in the mm system, which froze the entire machine. I

[PATCH for-4.9 1/5] blk-mq: Avoid memory reclaim when remapping queues

From: Gabriel Krisman Bertazi [ Upstream commit 36e1f3d107867b25c616c2fd294f5a1c9d4e5d09 ] While stressing memory and IO at the same time we changed SMT settings, we were able to consistently trigger deadlocks in the mm system, which froze the entire machine. I

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

On 11/04/17 11:22 PM, Benjamin Herrenschmidt wrote: > Another issue of course is that not all systems support P2P > between host bridges :-) (Though almost all switches can enable it). Yes, I'm either going to just let the user enable and test or limit it to switches only to start. However,

RFC: drop the T10 OSD code and its users

The only real user of the T10 OSD protocol, the pNFS object layout driver never went to the point of having shipping products, and the other two users (osdblk and exofs) were simple example of it's usage. The code has been mostly unmaintained for years and is getting in the way of block / SCSI

[PATCH 3/4] nfs: remove the objlayout driver

The objlayout code has been in the tree, but it's been unmaintained and no server product for it actually ever shipped. Signed-off-by: Christoph Hellwig --- Documentation/admin-guide/kernel-parameters.txt | 6 - Documentation/filesystems/nfs/pnfs.txt | 37 --

[PATCH 4/4] scsi: remove the SCSI OSD library

Now that all the users are gone the SCSI OSD library can be removed as well. Signed-off-by: Christoph Hellwig --- Documentation/scsi/osd.txt | 192 drivers/scsi/Makefile|1 - drivers/scsi/osd/Kbuild | 20 - drivers/scsi/osd/Kconfig |

[PATCH 1/4] block: remove the osdblk driver

This was just a proof of concept user for the SCSI OSD library, and never had any real users. Signed-off-by: Christoph Hellwig --- drivers/block/Kconfig | 16 -- drivers/block/Makefile | 1 - drivers/block/osdblk.c | 693 - 3

[Bug 195415] storage problem

https://bugzilla.kernel.org/show_bug.cgi?id=195415 Spam Script (spamscr...@kernel.org) changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH v2 3/4] sd: Make synchronize cache upon shutdown asynchronous

On Mon, Apr 10, 2017 at 10:54:01AM -0700, Bart Van Assche wrote: > This patch avoids that sd_shutdown() hangs on the SYNCHRONIZE CACHE > command if the block layer queue has been stopped by > scsi_target_block(). > > Signed-off-by: Bart Van Assche > Cc: Israel Rukshin

[PATCH] snic: fix spelling mistake: "Cann't" -> "Cannot"

From: Colin Ian King Trivial fix to spelling mistake in SNIC_ERR error message text, one cannot have "Cann't". Signed-off-by: Colin Ian King --- drivers/scsi/snic/snic_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH v4 0/6] Avoid that scsi-mq and dm-mq queue processing stalls sporadically

On Fri, Apr 07, 2017 at 11:16:48AM -0700, Bart Van Assche wrote: > Hello Jens, > > The six patches in this patch series fix the queue lockup I reported > recently on the linux-block mailing list. Please consider these patches > for inclusion in the upstream kernel. > Hey Bart, just out of

Re: [PATCH 10/25] loop: zero-fill bio on the submitting cpu

On Thu, Apr 06, 2017 at 05:39:29PM +0200, Christoph Hellwig wrote: > In thruth I've just audited which blk-mq drivers don't currently have a > complete callback, but I think this change is at least borderline useful. > > Signed-off-by: Christoph Hellwig > --- > drivers/block/loop.c

[Bug 195415] New: storage problem

https://bugzilla.kernel.org/show_bug.cgi?id=195415 Bug ID: 195415 Summary: storage problem Product: IO/Storage Version: 2.5 Kernel Version: 2.0 Hardware: All OS: Linux Tree: Mainline Status: NEW

[Bug 195405] not able to open a file

https://bugzilla.kernel.org/show_bug.cgi?id=195405 lavanya kalyankar (lavanyakalyankar7...@gmail.com) changed: What|Removed |Added Keywords|

[Bug 195405] New: not able to open a file

https://bugzilla.kernel.org/show_bug.cgi?id=195405 Bug ID: 195405 Summary: not able to open a file Product: SCSI Drivers Version: 2.5 Kernel Version: 2.3.69 Hardware: All OS: Linux Tree: Mainline

[PATCH 7/8] block: remove bio_no_advance_iter

Now that we don't have to support the odd Write Same special case we can simply increment the iter if the bio has data, else just manipulate bi_size directly. Signed-off-by: Christoph Hellwig --- include/linux/bio.h | 13 +++-- 1 file changed, 3 insertions(+), 10

[PATCH 3/8] sd: remove write same support

There are no more end-users of REQ_OP_WRITE_SAME left, so we can start deleting it. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 70 --- drivers/scsi/sd_zbc.c | 1 - 2 files changed, 71 deletions(-) diff --git

[PATCH 6/8] block: remove REQ_OP_WRITE_SAME support

Signed-off-by: Christoph Hellwig --- block/bio.c | 3 -- block/blk-core.c| 11 +- block/blk-lib.c | 90 - block/blk-merge.c | 32 block/blk-settings.c| 16

[PATCH 8/8] block: use bio_has_data to check if a bio has bvecs

Now that Write Same is gone and discard bios never have a payload we can simply use bio_has_data as an indicator that the bio has bvecs that need to be handled. Signed-off-by: Christoph Hellwig --- block/bio.c | 8 +--- block/blk-merge.c | 9 +

[PATCH 5/8] dm: remove write same support

Signed-off-by: Christoph Hellwig --- drivers/md/dm-core.h | 1 - drivers/md/dm-io.c| 21 + drivers/md/dm-linear.c| 1 - drivers/md/dm-mpath.c | 1 - drivers/md/dm-rq.c| 3 --- drivers/md/dm-stripe.c| 4

[PATCH 2/8] target/iblock: convert WRITE_SAME to blkdev_issue_zeroout

From: Nicholas Bellinger The people who are actively using iblock_execute_write_same_direct() are doing so in the context of ESX VAAI BlockZero, together with EXTENDED_COPY and COMPARE_AND_WRITE primitives. In practice though I've not seen any users of IBLOCK WRITE_SAME

[PATCH 1/8] drbd: drop REQ_OP_WRITE_SAME support

Linux only used it for zeroing, for which we have better methods now. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 28 ++ drivers/block/drbd/drbd_nl.c | 60 -- drivers/block/drbd/drbd_receiver.c

[PATCH 4/8] md: drop WRITE_SAME support

Signed-off-by: Christoph Hellwig --- drivers/md/linear.c| 1 - drivers/md/md.h| 7 --- drivers/md/multipath.c | 1 - drivers/md/raid0.c | 2 -- drivers/md/raid1.c | 4 +--- drivers/md/raid10.c| 1 - drivers/md/raid5.c | 1 - 7 files changed, 1

remove REQ_OP_WRITE_SAME

Now that we are using REQ_OP_WRITE_ZEROES for all zeroing needs in the kernel there is very little use left for REQ_OP_WRITE_SAME. We only have two callers left, and both just export optional protocol features to remote systems: DRBD and the target code. For the target code the only real use

Re: kill req->errors

Any more comments on these patches? I'd like to make some progress on this work.

Re: kill req->errors

On Thu, Apr 06, 2017 at 04:00:24PM -0400, Konrad Rzeszutek Wilk wrote: > You wouldn't have a git tree to easily test it? Thanks. Did you manage to give it a spin now that I pointed you to the git tree?

Re: Race to power off harming SATA SSDs

Am Dienstag, 11. April 2017, 11:31:29 CEST schrieb Henrique de Moraes Holschuh: > On Tue, 11 Apr 2017, Martin Steigerwald wrote: > > I do have a Crucial M500 and I do have an increase of that counter: > > > > martin@merkaba:~[…]/Crucial-M500> grep "^174" smartctl-a-201* > >

Re: [PATCH v2] scsi: return correct blkprep status code in case scsi_init_io() fails.

On 04/12/2017 09:21 AM, Johannes Thumshirn wrote: > When instrumenting the SCSI layer to run into the > !blk_rq_nr_phys_segments(rq) case the following warning emitted from the > block layer: > > blk_peek_request: bad return=-22 > > This happens because since commit fd3fc0b4d730 ('scsi: don't

[PATCH v2] scsi: return correct blkprep status code in case scsi_init_io() fails.

When instrumenting the SCSI layer to run into the !blk_rq_nr_phys_segments(rq) case the following warning emitted from the block layer: blk_peek_request: bad return=-22 This happens because since commit fd3fc0b4d730 ('scsi: don't BUG_ON() empty DMA transfers') we return the wrong error value

Re: [GIT PULL] target fixes for v4.11-rc7

On Tue, Apr 11, 2017 at 9:47 PM, Nicholas A. Bellinger wrote: > Hi Linus, > > Here are the outstanding target-pending bug-fixes for v4.11-rc7. So I'm pulling this, but I'm getting real tired of this crap. We're late in the rc's, I shouldn['t be getting pull requests of

Re: [PATCH RESEND] scsi: return correct blkprep status code in case scsi_init_io() fails.

On Tue, Apr 11, 2017 at 06:43:22PM +, Bart Van Assche wrote: > On Tue, 2017-04-11 at 09:46 +0200, Johannes Thumshirn wrote: > > When instrumenting the SCSI layer to run into the > > !blk_rq_nr_phys_segments(rq) case the following warning emitted from the > > block layer: > > > >

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

On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote: > 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