[PATCH] target/user: Fix possible overwrite of t_data_sg's last iov[]

From: Xiubo Li If there has BIDI data, its first iov[] will overwrite the last iov[] for se_cmd->t_data_sg. To fix this, we can just increase the iov pointer, but this may introuduce a new memory leakage bug: If the se_cmd->data_length and

[scsi:misc 40/55] arch/alpha/include/asm/atomic.h:20:38: error: 'refcount_t {aka struct refcount_struct}' has no member named 'counter'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc head: 2559a1ef688f933835912c731bed2254146a9b04 commit: 61d8658b4a435eac729966cc94cdda077a8df5cd [40/55] scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework. config: alpha-allyesconfig (attached as .config)

Re: [PATCH v2] scsi: ufs: Factor out ufshcd_read_desc_param

> "Michal" == Potomski, MichalX writes: Michal> Since in UFS 2.1 specification some of the descriptor lengths Michal> differs from 2.0 specification and some devices, which are Michal> reporting spec version 2.0 have different descriptor lengths we Michal> can not

Re: [PATCH] scsi: aacraid: remove redundant zero check on ret

> "Colin" == Colin King writes: Colin, Colin> The check for ret being zero is redundant as a few statements Colin> earlier we break out of the while loop if ret is non-zero. Thus Colin> we can remove the zero check and also the dead-code non-zero case Colin> too.

Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

> "Bart" == Bart Van Assche writes: Bart, Bart> Sorry but I still don't understand why the two checks are Bart> different. How about the (untested) patch below? The approach Bart> below avoids that the check is duplicated and - at least in my Bart> opinion -

Re: [PATCH] qedi: Fix memory leak in tmf response processing.

> "Manish" == Manish Rangankar writes: Manish, Applied to 4.11/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: lpfc: use div_u64 for 64-bit division

> "Arnd" == Arnd Bergmann writes: Arnd> The new debugfs output causes a link error on 32-bit Arnd> architectures: ERROR: "__aeabi_uldivmod" Arnd> [drivers/scsi/lpfc/lpfc.ko] undefined! Arnd> This code is not performance critical, so we can simply use Arnd> div_u64(). Applied

Re: [PATCH] scsi: lpfc: use proper format string for dma_addr_t

> "Arnd" == Arnd Bergmann writes: Arnd> dma_addr_t may be either u32 or u64, depending on the kernel Arnd> configuration, and we get a warning for the 32-bit case: Applied to 4.11/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi_error: count medium access timeout only once per EH run

> "Ewan" == Ewan D Milne writes: Ewan, Ewan> So, this is good, the current implementation has a flaw in that Ewan> under certain conditions, a device will get offlined immediately, Ewan> (i.e. if there are a few medium access commands pending, and they Ewan> all timeout),

Re: [PATCH 2/2] Add S6 support

> "Charles" == Charles Chiou writes: Charles, Charles> Hi all, Ping? Does this patch has any issue need to fix? Thank Charles> you. I'm hoping somebody will review it soon. However, we're in the middle of the 4.11 merge window so people are mostly focused on

[scsi:misc 40/55] arch/ia64/include/asm/atomic.h:24:38: error: 'refcount_t {aka struct refcount_struct}' has no member named 'counter'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc head: 2559a1ef688f933835912c731bed2254146a9b04 commit: 61d8658b4a435eac729966cc94cdda077a8df5cd [40/55] scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework. config: ia64-allmodconfig (attached as .config)

Re: SCSI regression in 4.11

On 02/27/2017 06:19 PM, Stephen Hemminger wrote: > On Mon, 27 Feb 2017 15:30:30 -0800 > Stephen Hemminger wrote: > >> Something in SCSI in 4.11 broke booting on Hyper-V Generation 2 VM with 8 >> VCPU and 4G of memory. >> Both Linus's current tree (4.11 pre-rc1) and

Re: [PATCH] target/user: Add daynmic growing data area featuresupport

Hi Mike Thanks verrry much for your work and test cases. From: Xiubo Li Currently for the TCMU, the ring buffer size is fixed to 64K cmd area + 1M data area, and this will be bottlenecks for high iops. Hi Xiubo, thanks for your work. daynmic -> dynamic Have

Re: [Lsf-pc] [LSF/MM TOPIC] do we really need PG_error at all?

On Tue, 2017-02-28 at 10:32 +1100, NeilBrown wrote: > On Mon, Feb 27 2017, Andreas Dilger wrote: > > > > > My thought is that PG_error is definitely useful for applications to get > > correct errors back when doing write()/sync_file_range() so that they know > > there is an error in the data

Re: SCSI regression in 4.11

On Mon, 27 Feb 2017 15:30:30 -0800 Stephen Hemminger wrote: > Something in SCSI in 4.11 broke booting on Hyper-V Generation 2 VM with 8 > VCPU and 4G of memory. > Both Linus's current tree (4.11 pre-rc1) and linux-next fail in a similar > manner. It looks like some

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, 2017-02-27 at 15:51 -0700, Andreas Dilger wrote: > On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: > > > On Sun, Feb 26 2017, James Bottomley wrote: > > > > > > > On Mon, 2017-02-27 at 08:03 +1100, NeilBrown

Re: [PATCHv2 5/5] scsi: make asynchronous aborts mandatory

On Wed, 2017-02-22 at 17:07 +0100, Hannes Reinecke wrote: > There hasn't been any reports for HBAs where asynchronous abort > would not work, so we should make it mandatory and remove > the fallback. Reviewed-by: Bart Van Assche

[PATCH v2] libiscsi: add lock around task lists to fix list corruption regression

There's a rather long standing regression from the commit "libiscsi: Reduce locking contention in fast path" Depending on iSCSI target behavior, it's possible to hit the case in iscsi_complete_task where the task is still on a pending list (!list_empty(>running)). When that happens the task is

Re: [PATCH] target/user: Add daynmic growing data area feature support

On 02/22/2017 02:32 PM, Andy Grover wrote: > On 02/17/2017 01:24 AM, lixi...@cmss.chinamobile.com wrote: >> > From: Xiubo Li >> > >> > Currently for the TCMU, the ring buffer size is fixed to 64K cmd >> > area + 1M data area, and this will be bottlenecks for high

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, Feb 27 2017, Andreas Dilger wrote: > > My thought is that PG_error is definitely useful for applications to get > correct errors back when doing write()/sync_file_range() so that they know > there is an error in the data that _they_ wrote, rather than receiving an > error for data that

[ANNOUNCE]: Broadcom (Emulex) FC Target driver - efct

I'd like to announce the availability of the Broadcom (Emulex) FC Target driver - efct. This driver has been part of the Emulex OneCore Storage SDK tool kit for Emulex SLI-4 adapters. The SLI-4 adapters support 16Gb/s and higher adapters. Although this kit has supported FCoE in the past, it is

[bug report] scsi: lpfc: NVME Target: Receive buffer updates

Hello James Smart, This is a semi-automatic email about new static checker warnings. The patch 2d7dbc4c2775: "scsi: lpfc: NVME Target: Receive buffer updates" from Feb 12, 2017, leads to the following Smatch complaint: drivers/scsi/lpfc/lpfc_sli.c:15194 lpfc_mrq_create() warn:

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Feb 27, 2017, at 8:07 AM, Jeff Layton wrote: > > On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: >> On Sun, Feb 26 2017, James Bottomley wrote: >> >>> On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: On Sun, Feb 26 2017, James Bottomley wrote: >

Re: [PATCHv2 3/5] scsi_error: do not escalate failed EH command

On Wed, 2017-02-22 at 17:07 +0100, Hannes Reinecke wrote: > When a command is sent as part of the error handling there > is not point whatsoever to start EH escalation when that > command fails; we are _already_ in the error handler, > and the escalation is about to commence anyway. > So just call

Re: [PATCHv2 4/5] scsi: make scsi_eh_scmd_add() always succeed

On Wed, 2017-02-22 at 17:07 +0100, Hannes Reinecke wrote: > spin_lock_irqsave(shost->host_lock, flags); > + WARN_ON(shost->shost_state != SHOST_RUNNING && > + shost->shost_state != SHOST_CANCEL && > + shost->shost_state != SHOST_RECOVERY && > +

Re: Kernel crash with 4.10 trying to remove scsi disks

Hi Johannes, I don't think this crash was newly introduced with 4.10. I had another run with 4.10 and that one completed successfully. So not sure what is causing this kernel crash. Thanks Farhan On 02/27/2017 05:35 AM, Johannes Thumshirn wrote: On 02/24/2017 04:07 PM, Farhan Ali wrote:

Re: [PATCHv2 0/5] SCSI EH cleanup

On Fri, 2017-02-24 at 08:15 +0100, Hannes Reinecke wrote: > scsi_abort_command() (ie the call which triggers async aborts) is only > called if the .eh_timed_out() callback returns BLK_EH_NOT_HANDLED. > So during reconnects we will not schedule any calls to async aborts. > We _might_ have scheduled

Re: [PATCHv2 2/5] scsi: make eh_eflags persistent

On Wed, 2017-02-22 at 17:07 +0100, Hannes Reinecke wrote: > To detect if a failed command has been retried we must not > clear scmd->eh_eflags when EH finishes. > The flag should be persistent throughout the lifetime > of the command. Hello Hannes, Is it on purpose that this patch does not

[PATCH] scsi: lpfc: use div_u64 for 64-bit division

The new debugfs output causes a link error on 32-bit architectures: ERROR: "__aeabi_uldivmod" [drivers/scsi/lpfc/lpfc.ko] undefined! This code is not performance critical, so we can simply use div_u64(). Fixes: bd2cdd5e400f ("scsi: lpfc: NVME Initiator: Add debugfs support") Fixes: 2b65e18202fd

[PATCH] scsi: lpfc: use proper format string for dma_addr_t

dma_addr_t may be either u32 or u64, depending on the kernel configuration, and we get a warning for the 32-bit case: drivers/scsi/lpfc/lpfc_nvme.c: In function 'lpfc_nvme_ls_req': drivers/scsi/lpfc/lpfc_logmsg.h:52:52: error: format '%llu' expects argument of type 'long long unsigned int', but

Re: [PATCH] scsi_error: count medium access timeout only once per EH run

On Thu, 2017-02-23 at 11:27 +0100, Hannes Reinecke wrote: > The current medium access timeout counter will be increased for > each command, so if there are enough failed commands we'll hit > the medium access timeout for even a single failure. > Fix this by making the timeout per EH run, ie the

how to unmap pages in an anonymous mmap?

On 02/26/2017 09:59 PM, Xiubo Li wrote: >> But, We likely don't want to release memory from the data area anyways >> while active, in any case. How about if we set a timer when active >> commands go to zero, and then reduce data area to some minimum if no new >> cmds come in before timer expires?

Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

On Mon, 2017-02-27 at 11:13 -0600, Steve Magnani wrote: > On 02/27/2017 10:13 AM, Bart Van Assche wrote: > > Why are the two checks slightly different? Could the same code be used for > > both checks? > > The checks are different because with READ CAPACITY(16) a _really_ huge > device could

Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

Hi Bart - Thanks for taking the time to look this over. On 02/27/2017 10:13 AM, Bart Van Assche wrote: On Mon, 2017-02-27 at 09:22 -0600, Steven J. Magnani wrote: @@ -2122,7 +2122,10 @@ static int read_capacity_16(struct scsi_ return -ENODEV; } - if

[bug report] scsi: lpfc: NVME Target: Base modifications

Hello James Smart, This is a semi-automatic email about new static checker warnings. The patch f358dd0ca26c: "scsi: lpfc: NVME Target: Base modifications" from Feb 12, 2017, leads to the following Smatch complaint: drivers/scsi/lpfc/lpfc_mem.c:650 lpfc_sli4_nvmet_alloc() warn:

[bug report] scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.

Hello Dupuis, Chad, This is a semi-automatic email about new static checker warnings. The patch 61d8658b4a43: "scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework." from Feb 15, 2017, leads to the following Smatch complaint: drivers/scsi/qedf/qedf_main.c:1565 qedf_vport_destroy()

[bug report] scsi: lpfc: NVME Initiator: Merge into FC discovery

Hello James Smart, This is a semi-automatic email about new static checker warnings. The patch a0f2d3ef374f: "scsi: lpfc: NVME Initiator: Merge into FC discovery" from Feb 12, 2017, leads to the following Smatch complaint: drivers/scsi/lpfc/lpfc_ct.c:943 lpfc_cmpl_ct_cmd_gft_id()

Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

On Mon, 2017-02-27 at 09:22 -0600, Steven J. Magnani wrote: > @@ -2122,7 +2122,10 @@ static int read_capacity_16(struct scsi_ > return -ENODEV; > } > > - if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xULL)) { > + /* Make sure logical_to_sectors() won't

[bug report] scsi: lpfc: NVME Initiator: Base modifications

Hello James Smart, The patch 895427bd012c: "scsi: lpfc: NVME Initiator: Base modifications" from Feb 12, 2017, leads to the following static checker warning: [ Heck... I just decided to report all the static checker warnings for this file. - dan ]

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Mon, 2017-02-27 at 13:52 +0100, Romain Perier wrote: > > I also wonder if you've in fact converted all of the > > pci_pool struct and function uses why a new checkpatch > > test is needed at all. > > That's just to avoid futures mistakes/uses. When all instances and macro definitions are

[bug report] scsi: aacraid: Reorder Adapter status check

Hello Raghava Aditya Renukunta, The patch c421530bf848: "scsi: aacraid: Reorder Adapter status check" from Feb 16, 2017, leads to the following static checker warning: drivers/scsi/aacraid/src.c:471 aac_src_check_health() warn: was shift intended here '(status > 16)'

[PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF

When the kernel is compiled _without_ support for large (>= 2TiB) block devices, code in the sd driver's read_capacity() routines rejects devices whose count of native-sized blocks does not fit in the 32 bit sector_t type. A device reporting 4294967296 512-byte blocks will be rejected, but a

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, 2017-02-27 at 11:27 +1100, NeilBrown wrote: > On Sun, Feb 26 2017, James Bottomley wrote: > > > On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: > > > On Sun, Feb 26 2017, James Bottomley wrote: > > > > > > > [added linux-scsi and linux-block because this is part of our error > > > >

Re: [PATCH v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

Hi Kishon, On 02/27/2017 10:56 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Thursday 23 February 2017 12:20 AM, Alim Akhtar wrote: >> On Fri, Feb 3, 2017 at 2:49 PM, Alim Akhtar wrote: >>> Hi Kishon, >>> >>> >>> On 11/19/2015 07:09 PM, Kishon Vijay Abraham I wrote:

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

Hello, Le 27/02/2017 à 13:38, Joe Perches a écrit : > On Mon, 2017-02-27 at 13:26 +0100, Romain Perier wrote: >> Hello, >> >> >> Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit : >>> On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote: pci_pool_*() functions should be replaced

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Mon, 2017-02-27 at 13:26 +0100, Romain Perier wrote: > Hello, > > > Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit : > > On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote: > > > pci_pool_*() functions should be replaced by the corresponding functions > > > in the DMA pool

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

Hello, Le 27/02/2017 à 12:22, Peter Senna Tschudin a écrit : > On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote: >> pci_pool_*() functions should be replaced by the corresponding functions >> in the DMA pool API. This adds support to check for use of these pci >> functions and

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Mon, 2017-02-27 at 12:22 +0100, Peter Senna Tschudin wrote: > On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote: > > pci_pool_*() functions should be replaced by the corresponding functions > > in the DMA pool API. This adds support to check for use of these pci > > functions and

Re: [PATCH v3 12/20] scsi: mpt3sas: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:17PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 11/20] scsi: megaraid: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:16PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 17/20] usb: gadget: pch_udc: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:22PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 13/20] scsi: mvsas: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:18PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 10/20] scsi: lpfc: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:15PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. It also updates > some comments, accordingly. > Reviewed-by: Peter Senna Tschudin

Re: [PATCH v3 19/20] PCI: Remove PCI pool macro functions

On Sun, Feb 26, 2017 at 08:24:24PM +0100, Romain Perier wrote: > Now that all the drivers use dma pool API, we can remove the macro > functions for PCI pool. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier > --- >

Re: [PATCH v3 20/20] checkpatch: warn for use of old PCI pool API

On Sun, Feb 26, 2017 at 08:24:25PM +0100, Romain Perier wrote: > pci_pool_*() functions should be replaced by the corresponding functions > in the DMA pool API. This adds support to check for use of these pci > functions and display a warning when it is the case. > I guess Joe Perches did sent

Re: [PATCH v3 18/20] usb: host: Remove remaining pci_pool in comments

On Sun, Feb 26, 2017 at 08:24:23PM +0100, Romain Perier wrote: > This replaces remaining occurences of pci_pool by dma_pool, as > this is the new API that could be used for that purpose. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 07/20] wireless: ipw2200: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:12PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: [PATCH v3 00/20] Replace PCI pool by DMA pool API

On Sun, Feb 26, 2017 at 08:24:05PM +0100, Romain Perier wrote: > The current PCI pool API are simple macro functions direct expanded to > the appropriated dma pool functions. The prototypes are almost the same > and semantically, they are very similar. I propose to use the DMA pool > API directly

Re: [PATCH v3 06/20] mlx5: Replace PCI pool old API

On Sun, Feb 26, 2017 at 08:24:11PM +0100, Romain Perier wrote: > The PCI pool API is deprecated. This commits replaces the PCI pool old > API by the appropriated function with the DMA pool API. > Reviewed-by: Peter Senna Tschudin > Signed-off-by: Romain Perier

Re: Kernel crash with 4.10 trying to remove scsi disks

On 02/24/2017 04:07 PM, Farhan Ali wrote: > Hello, > > I have noticed a kernel crash with 4.10 kernel in our s390 environment, > running a test trying to remove scsi disks. Here is a snippet of the > kernel crash message: Hi Farhan, Is this crash newly introduced with 4.10? Do you maybe have a