Re: [PATCH 14/47] scsi: Use Scsi_Host as argument for eh_host_reset_handler

On 06/28/2017 10:32 AM, Hannes Reinecke wrote: Issuing a host reset should not rely on any commands. So use Scsi_Host as argument for eh_host_reset_handler. Signed-off-by: Hannes Reinecke --- Documentation/scsi/scsi_eh.txt | 2 +-

Re: [PATCH 09/47] zfcp: open-code fc_block_scsi_eh() for host reset

On 06/28/2017 10:32 AM, Hannes Reinecke wrote: When issuing a host reset we should be waiting for all ports to become unblocked; just waiting for one might be resulting in host reset to return too early. Signed-off-by: Hannes Reinecke --- drivers/s390/scsi/zfcp_scsi.c | 27

Re: Please help me with kernel hung

On Mon, 24 Jul 2017, Михаил Гаврилов wrote: > Hi guys. I hope what I wrote to appropriate mailing list. Can anybody > look in hung issue below: > > [ 246.751384] kernel: INFO: task scsi_eh_6:388 blocked for more than > 120 seconds. > [ 246.752085] kernel: Not tainted

Re: [PATCH 09/47] zfcp: open-code fc_block_scsi_eh() for host reset

Hi Hannes, unfortunately I only realized now by accident that there's stuff to review. Would be nice to send it also explicitly to driver maintainers in addition to the list. Since you've asked for this multiple times, I happened to just now code a patch series of 6 patches in order to

Re: [PATCH 15/47] scsi_transport_fc: Use fc_rport as argument for fc_block_scsi_eh

On 06/28/2017 10:32 AM, Hannes Reinecke wrote: fc_block_scsi_eh() works on a remote port, so we should be using that as an argument, and not the scsi command. diff --git a/drivers/s390/scsi/zfcp_scsi.c b/drivers/s390/scsi/zfcp_scsi.c index d7d4a63..e3160fc 100644 ---

Re: [PATCH] scsi: qedi: select CONFIG_ISCSI_BOOT_SYSFS

On 21/07/17, 9:41 PM, "Arnd Bergmann" wrote: >Without the base library support, we get a link failure > >drivers/scsi/qedi/qedi_main.o: In function `__qedi_probe.constprop.0': >qedi_main.c:(.text+0x2d8e): undefined reference to >`iscsi_boot_create_target'

Re: [PATCH] aic7xxx: fix firmware build with O=path

On Mon, 24 Jul 2017 09:00:41 +0200, Hannes Reinecke wrote: > On 07/21/2017 08:51 PM, Jakub Kicinski wrote: > > On Tue, 18 Jul 2017 18:58:34 -0700, Jakub Kicinski wrote: > >> Building firmware with O=path was apparently broken in aic7 for ever. > >> Message of the previous commit to the Makefile

Re: Please help me with kernel hung

On Tue, 25 Jul 2017, Михаил Гаврилов wrote: > Sure. > I've get it by command: > journalctl -b -1 -k --no-host -oshort-monotonic > it's enough? Or needed another logging level? > Thanks for respond. This is enough for now. The problem is that a USB transfer is started but never stopped, which

Re: [PATCH 24/47] zfcp: use scsi device as argument for zfcp_task_mgmt_function()

On 06/28/2017 10:32 AM, Hannes Reinecke wrote: zfcp_task_mgmt_function() is only used for lun and device reset, so it should be using the scsi device as an argument, not the scsi command. Signed-off-by: Hannes Reinecke --- drivers/s390/scsi/zfcp_ext.h | 2 +-

Re: [PATCH 0/7] Enable iSCSI offload drivers to use information from iface.

On Wed, Jun 14, 2017 at 10:47 AM, Robert LeBlanc wrote: > On Wed, Jun 14, 2017 at 3:20 AM, Rangankar, Manish > wrote: >> >> On 13/06/17 10:19 PM, "Robert LeBlanc" wrote: >> >>>On Wed, Jun 7, 2017 at 12:30 PM, Robert

Re: [PATCH 46/47] scsi: Move eh_device_reset_handler() to use scsi_device as argument

sparse review comments below... On 06/28/2017 10:33 AM, Hannes Reinecke wrote: When resetting a device we shouldn't depend on an existing SCSI device, so use 'struct scsi_device' as argument for eh_device_reset_handler(). Signed-off-by: Hannes Reinecke ---

Re: [PATCH 09/47] zfcp: open-code fc_block_scsi_eh() for host reset

On 07/24/2017 06:18 PM, Steffen Maier wrote: > Hi Hannes, > > unfortunately I only realized now by accident that there's stuff to > review. Would be nice to send it also explicitly to driver maintainers > in addition to the list. > Well, the entire patchset got send as an RFC anyway, and as such

Re: [PATCH 32/47] scsi: Use scsi_target as argument for eh_target_reset_handler()

On 06/28/2017 10:32 AM, Hannes Reinecke wrote: The target reset function should only depend on the scsi target, not the scsi command. Signed-off-by: Hannes Reinecke --- drivers/s390/scsi/zfcp_scsi.c | 20 ++-- drivers/scsi/scsi_debug.c

Re: [PATCH] scsi: Convert to using %pOF instead of full_name

Rob, > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. Applied to 4.14/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 00/22] gcc-7 -Wformat-* warnings

Arnd, > This series addresses all warnings that gcc-7 introduces for > -Wformat-overflow= and turns off the -Wformat-truncation by default > (they remain enabled with "make W=1"). Applied the SCSI patches. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/1] scsi: ufs: changing maintainer

Prabu, > As per internal decision, Joao Pinto will be maintainer for DWC UFS > driver. Applied to 4.14/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion

shuw...@redhat.com, > Found this issue by kmemleak, a few kb mem was leaked in > megasas_alloc_cmdlist_fusion when kzalloc failed for one > megasas_cmd_fusion allocation. Applied to 4.13/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] SCSI: remove DRIVER_ATTR() usage

Greg, > It's better to use the DRIVER_ATTR_RW() and DRIVER_ATTR_RO() macros to > explicitly show that this is a read/write or read/only sysfs file. So > convert the remaining SCSI drivers that use the old style to use the > newer macros. Applied to 4.14/scsi-queue. Thank you! -- Martin K.

Re: [PATCH] qedi: Add ISCSI_BOOT_SYSFS to Kconfig

Nilesh, > qedi uses iscsi_boot_sysfs to export the targets used for boot to > sysfs. Select the config option to make sure the module is built. Applied to 4.13/scsi-fixes. Whitespace was bad. Fixed. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi_transport_fc: return -EBUSY for deleted vport

Hannes, > When trying to delete a vport via 'vport_delete' sysfs attribute > we should be checking if the port is already in state VPORT_DELETING; > if so there's no need to do anything. Applied to 4.13/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] aic7xxx: fix firmware build with O=path

Jakub, > Building firmware with O=path was apparently broken in aic7 for ever. > Message of the previous commit to the Makefile (from 2008) mentions > this unfortunate state of affairs already. Fix this, mostly to make > randconfig builds more reliable. Applied to 4.13/scsi-fixes. Thank you!

Re: [PATCH] scsi: libcxgbi: add check for valid cxgbi_task_data

Varun, > In error case it is possible that ->cleanup_task() gets called without > calling ->alloc_pdu() in this case cxgbi_task_data is not valid, so > add a check for for valid cxgbi_task_data in cxgbi_cleanup_task(). Applied to 4.13/scsi-fixes, thanks! -- Martin K. Petersen Oracle

Re: [PATCH v2 00/13] mpt3sas driver NVMe support:

Is there any update on these patches ? Thanks, Suganath Prabu S On Fri, Jul 14, 2017 at 6:52 PM, Suganath Prabu S wrote: > Ventura Series controller are Tri-mode. The controller and > firmware are capable of supporting NVMe devices and > PCIe switches to

[PATCH] scsi_transport_fc: return -EBUSY for deleted vport

When trying to delete a vport via 'vport_delete' sysfs attribute we should be checking if the port is already in state VPORT_DELETING; if so there's no need to do anything. Signed-off-by: Hannes Reinecke --- drivers/scsi/scsi_transport_fc.c | 6 -- 1 file changed, 4

Re: [PATCH 26/28] visorhba: sanitze private device data allocation

On 07/19/2017 07:45 PM, Kershner, David A wrote: > > >> -Original Message- >> From: Hannes Reinecke [mailto:h...@suse.de] >> Sent: Wednesday, June 28, 2017 4:25 AM >> To: Christoph Hellwig >> Subject: [PATCH 26/28] visorhba: sanitze private device data allocation >> >>

Re: [PATCH] aic7xxx: fix firmware build with O=path

On 07/21/2017 08:51 PM, Jakub Kicinski wrote: > On Tue, 18 Jul 2017 18:58:34 -0700, Jakub Kicinski wrote: >> Building firmware with O=path was apparently broken in aic7 for ever. >> Message of the previous commit to the Makefile (from 2008) mentions >> this unfortunate state of affairs already.

[patch 1/5] scsi/bnx2fc: Plug CPU hotplug race

bnx2fc_process_new_cqes() has protection against CPU hotplug, which relies on the per cpu thread pointer. This protection is racy because it happens only partially with the per cpu fp_work_lock held. If the CPU is unplugged after the lock is dropped, the wakeup code can dereference a NULL pointer

[patch 0/5] scsi/bnx2*: Plug hotplug race, correct locking and simplify hotplug code

The conversion of the cpu hotplug locking to a percpu rwsem does not longer allow recursive locking of the hotplug lock. The BNX2I and BNX2FC drivers install/remove hotplug states with the hotplug lock held. The install/removal code acquired the hotplug lock as well. While looking into this, I

[patch 5/5] scsi/bnx2i: Simplify cpu hotplug code

The CPU hotplug related code of this driver can be simplified by: 1) Consolidating the callbacks into a single state. The CPU thread can be torn down on the CPU which goes offline. There is no point in delaying that to the CPU dead state 2) Let the core code invoke the online/offline

[patch 2/5] scsi/bnx2fc: Prevent recursive cpuhotplug locking

The BNX2FC module init/exit code installs/removes the hotplug callbacks with the cpu hotplug lock held. This worked with the old CPU locking implementation which allowed recursive locking, but with the new percpu rwsem based mechanism this is not longer allowed. Use the _cpuslocked() variants to

[patch 3/5] scsi/bnx2i: Prevent recursive cpuhotplug locking

The BNX2I module init/exit code installs/removes the hotplug callbacks with the cpu hotplug lock held. This worked with the old CPU locking implementation which allowed recursive locking, but with the new percpu rwsem based mechanism this is not longer allowed. Use the _cpuslocked() variants to

[patch 4/5] scsi/bnx2fc: Simplify CPU hotplug code

The CPU hotplug related code of this driver can be simplified by: 1) Consolidating the callbacks into a single state. The CPU thread can be torn down on the CPU which goes offline. There is no point in delaying that to the CPU dead state 2) Let the core code invoke the online/offline

RE: [PATCH v2 11/15] megaraid_sas: Set device queue_depth same as HBA can_queue value in scsi-mq mode

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, July 20, 2017 1:18 PM > To: Shivasharan Srikanteshwara > Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; martin.peter...@oracle.com; > the...@redhat.com; j...@linux.vnet.ibm.com; Sumit Saxena;