On 13/04/17 05:14, Uma Krishnan wrote:
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 d
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
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
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 the
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
>> allyesconfig builds of x8
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
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 can'
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 be tuned by a system admini
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 SCSI-MQ enabled, and simple ha
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 status bits are supported.
As a
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
l
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
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/common.
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. Ochs
Signed-off-by: Uma Kris
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 an additional, related
cleanu
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 -
drivers/scsi/cxlflash/sislite.h | 6 ++--
2 files changed, 80 inser
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 removal to avoid orphaned th
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 impacting existing code paths.
Si
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 port selection mask
register re
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
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/
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 issue, remove the existing port
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 interrupts are disabled, support
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
---
drivers/scsi/cxlflash/main.c | 24
1 file changed, 12 inse
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 API to schedule this processin
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 hardware interrupt handler.
Sig
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
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 rer
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 u
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 upstream?
>
> Obviously things
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 think that under memory stress co
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 think that under memory stress co
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, curr
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 cha
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 --
fs/nfs/Kconfig
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 | 49 -
drivers
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 files changed, 710
https://bugzilla.kernel.org/show_bug.cgi?id=195415
Spam Script (spamscr...@kernel.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
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
> Cc: Max Gurtovoy
> Cc: H
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 --git a/drivers/scsi/snic/snic_debugfs.c b/drivers/scsi/
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 curio
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 | 30
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
https://bugzilla.kernel.org/show_bug.cgi?id=195405
lavanya kalyankar (lavanyakalyankar7...@gmail.com) changed:
What|Removed |Added
Keywords||trivi
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
S
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 deletions(-)
diff --git
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 a/drivers/scsi/sd.c
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
block/bl
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 +
include/linux/bio.h | 21 ++
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 +---
drivers
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 for
anything other than V
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 | 38 +++--
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 insertion(+), 16 dele
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 case
Any more comments on these patches? I'd like to make some progress
on this work.
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?
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*
> > smartctl-a-2014-03-05.
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 BU
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 fro
57 matches
Mail list logo
