[PATCH] scsi: vmw-pvscsi: return DID_BUS_BUSY for adapter-initated aborts

The vmw_pvscsi driver returns DID_ABORT for commands aborted internally by the adapter, leading to the filesystem going read-only. Change the result to DID_BUS_BUSY, causing the kernel to retry the command. Signed-off-by: Jim Gill --- drivers/scsi/vmw_pvscsi.c | 2 +- 1 file

[PATCH] scsi: vmw-pvscsi: return DID_BUS_BUSY for adapter-initated aborts

The vmw_pvscsi driver returns DID_ABORT for commands aborted internally by the adapter, leading to the filesystem going read-only. Change the result to DID_BUS_BUSY, causing the kernel to retry the command. Signed-off-by: Jim Gill --- drivers/scsi/vmw_pvscsi.c | 2 +- 1 file

Re: [VERY EARLY RFC 00/13] Rework SCSI results handling

Johannes, > here's a early preview of my SCSI results rework so we can eventually > discuss things next week at LSF/MM (it still has compiler errors on > aic7xxx and scsi_debug). Here's what I'd like to see: - Forget about cramming everything into that dreaded u32 result. Bart's suggestion

Re: [PATCH] [v2] scsi: ips: fix firmware timestamps for 32-bit

Arnd, > do_gettimeofday() is deprecated since it will stop working in 2038 on > 32-bit platforms, leading to incorrect times passed to the firmware. > On 64-bit platforms the current code appears to be fine, as the > calculation passes an 8-bit century number into the firmware that can >

Re: [PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

Arnd, > do_gettimeofday() is deprecated because of the y2038 overflow. Here, > we use the result to pass into a 32-bit field in the firmware, which > still risks an overflow, but if the firmware is written to expect > unsigned values, it can at least last until y2106, and there is not > much we

Re: [PATCH scsi-next] scsi: mvumi: Using module_pci_driver.

YueHaibing, > Remove boilerplate code by using macro module_pci_driver. Applied to 4.18/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH][V2] isci: Fix infinite loop in while loop

Colin, > In the case when the phy_mask is bitwise anded with the phy_index bit > is zero the continue statement currently jumps to the next iteration > of the while loop and phy_index is never actually incremented, > potentially causing an infinite loop if phy_index is less than > SCI_MAX_PHS.

Re: [PATCH v3 0/6] scsi: handle special return codes for ABORTED COMMAND

Martin, > Here is another attempt to handle the special return codes for ABORTED > COMMAND for certain SCSI devices. Following MKP's recommendation, I've > created two new BLIST flags, simplifying the code in scsi_error.c > compared to the previous versions. Rather than using "free" bits, I >

Re: [PATCH v2] target: Fix Fortify_panic kernel exception

Bryant, > The bug exists in the memcmp in which the length passed in must be > guaranteed to be 1. This bug currently exists because the second > pointer passed in, can be smaller than the cmd->data_length, which > causes a fortify_panic. > > The fix is to use memchr_inv instead to find whether

Re: target: clean up kernel-doc and add driver-api document

Randy, > This patch series fixes kernel-doc warnings in drivers/target/ and its > header files, then adds a Documentation driver-api chapter for target > driver interfaces. Applied to 4.18/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: Representative Needed.

Good day, I am seeking your concept with great gratitude to present you as a representative to carry out business transactions with a reasonable share upon your interest and cooperation to work with us in trust. If interested please get back. Regards Kingsley --- This email has been

Re: [PATCH] bsg referencing bus driver module

> This patch isn't applyable because your mailer has changed all the tabs > to spaces. > > I also think there's no need to do it this way. I think what we need > is for fc_bsg_remove() to wait until the bsg queue is drained. It does > look like the author thought this happened otherwise the

Re: [PATCH 1/2] scsi: st: Replace GFP_ATOMIC with GFP_KERNEL in st_probe

Jia-Ju, > st_probe() is never called in atomic context. Applied patches 1 and 2 to 4.18/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v2 01/14] mpt3sas: Bug fix for big endian systems.

Chaitra, A few comments: > @@ -426,7 +427,7 @@ static void _clone_sg_entries(struct MPT3SAS_ADAPTER *ioc, > dst_addr_phys = _base_get_chain_phys(ioc, > smid, sge_chain_count); > WARN_ON(dst_addr_phys >

Re: usercopy whitelist woe in scsi_sense_cache

Hi. On 20.04.2018 22:23, Kees Cook wrote: I don't know the "how", I only found the "what". :) If you want, grab the reproducer VM linked to earlier in this thread; it'll hit the problem within about 30 seconds of running the reproducer. Just to avoid a possible confusion I should note that

Re: usercopy whitelist woe in scsi_sense_cache

On Thu, Apr 19, 2018 at 2:32 AM, Paolo Valente wrote: > I'm missing something here. When the request gets completed in the > first place, the hook bfq_finish_requeue_request gets called, and that > hook clears both ->elv.priv elements (as the request has a non-null >

Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write

Long, > This is a best effort for estimating on how busy the ring buffer is > for that channel, based on available buffer to write in percentage. It > is still possible that at the time of actual ring buffer write, the > space may not be available due to other processes may be writing at > the

Re: [PATCH v2] storvsc: Set up correct queue depth values for IDE devices

Long, > If num_cpus=1, we don't have any sub channels. > > The host offers one sub channel for VM with 5 CPUs, after that it offers > an additional sub channel every 4 CPUs. > > The primary channel is always offered. Applied to 4.17/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux

[PATCH] [v2] scsi: ips: fix firmware timestamps for 32-bit

do_gettimeofday() is deprecated since it will stop working in 2038 on 32-bit platforms, leading to incorrect times passed to the firmware. On 64-bit platforms the current code appears to be fine, as the calculation passes an 8-bit century number into the firmware that can represent times long in

[PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

do_gettimeofday() is deprecated because of the y2038 overflow. Here, we use the result to pass into a 32-bit field in the firmware, which still risks an overflow, but if the firmware is written to expect unsigned values, it can at least last until y2106, and there is not much we can do about it.

Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write

On Thu, 19 Apr 2018 14:54:24 -0700 Long Li wrote: > From: Long Li > > This is a best effort for estimating on how busy the ring buffer is for > that channel, based on available buffer to write in percentage. It is still > possible that at the

[Bug 199435] HPSA + P420i resetting logical Direct-Access never complete

https://bugzilla.kernel.org/show_bug.cgi?id=199435 --- Comment #7 from Anthony Hausman (anthonyhaussm...@gmail.com) --- I had a similar stack trace: Apr 20 14:57:18 kernel: INFO: task jbd2/sdt-8:10890 blocked for more than 120 seconds. Apr 20 14:57:18 kernel: Tainted: G OE

Re: [PATCH] isci: Fix infinite loop in while loop

On 20/04/18 10:45, James Bottomley wrote: > On Fri, 2018-04-20 at 10:03 +0100, Colin King wrote: >> From: Colin Ian King >> >> In the case when the phy_mask is bitwise anded with the >> phy_index bit is zero the continue statement currently jumps >> to the next iteration

[PATCH][V2] isci: Fix infinite loop in while loop

From: Colin Ian King In the case when the phy_mask is bitwise anded with the phy_index bit is zero the continue statement currently jumps to the next iteration of the while loop and phy_index is never actually incremented, potentially causing an infinite loop if

Re: [PATCH] bsg referencing bus driver module

On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote: > Updated: rebased on recent Linux, cc-ed maintainers per instructions > in MAINTAINERS file > > From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00 > 2001 > From: Anatoliy Glagolev > Date: Thu,

Re: [PATCH] isci: Fix infinite loop in while loop

On Fri, 2018-04-20 at 10:03 +0100, Colin King wrote: > From: Colin Ian King > > In the case when the phy_mask is bitwise anded with the > phy_index bit is zero the continue statement currently jumps > to the next iteration of the while loop and phy_index is > never

[PATCH] isci: Fix infinite loop in while loop

From: Colin Ian King In the case when the phy_mask is bitwise anded with the phy_index bit is zero the continue statement currently jumps to the next iteration of the while loop and phy_index is never actually incremented, potentially causing an infinite loop if

[PATCH 3/3] scsi: avoid to hold host-wide counter of host_busy for scsi_mq

It isn't necessary to check the host depth in scsi_queue_rq() any more since it has been respected by blk-mq before calling scsi_queue_rq() via getting driver tag. Lots of LUNs may attach to same host, and per-host IOPS may reach millions level, so we should avoid to this expensive atomic

[PATCH 2/3] scsi: read host_busy via scsi_host_busy()

No functional change, just replace the direct read of scsi_host->host_busy with scsi_host_busy(). Cc: Omar Sandoval , Cc: "Martin K. Petersen" , Cc: James Bottomley , Cc: Christoph Hellwig , Cc: Don

[PATCH 0/3] scsi: scsi-mq: don't hold host_busy in IO path

Hi, This patches removes the expensive atomic opeation on host-wide counter of .host_busy for scsi-mq, and it is observed that IOPS can be increased by 15% with this change in IO test over scsi_debug. Ming Lei (3): scsi: introduce scsi_host_busy() scsi: read host_busy via scsi_host_busy()

[PATCH 1/3] scsi: introduce scsi_host_busy()

This patch introduces SCSI middle layer API of scsi_host_busy() for drivers to read the host-wide counter of scsi_host->host_busy. Cc: Omar Sandoval , Cc: "Martin K. Petersen" , Cc: James Bottomley , Cc: Christoph