Re: [PATCH -next] misc: ibmvmc: Use GFP_ATOMIC under spin lock

IC); > > if (!buffer) { > *dma_handle = 0; > Reviewed-by: Bryant G. Ly

Re: [PATCH -next] misc: ibmvmc: Use GFP_ATOMIC under spin lock

IC); > > if (!buffer) { > *dma_handle = 0; > Reviewed-by: Bryant G. Ly

Re: [PATCH 1/6] target: Fix QUEUE_FULL + SCSI task attribute handling

t; matching what target_execute_cmd() does. > > Cc: Michael Cyr <mike...@linux.vnet.ibm.com> > Cc: Bryant G. Ly <bryan...@linux.vnet.ibm.com> > Cc: Mike Christie <mchri...@redhat.com> > Cc: Hannes Reinecke <h...@suse.com> > Signed-off-by: Nicholas Bellinger <n...@linux-iscsi.org> > --- > Reviewed-by: Bryant G. Ly <bryan...@linux.vnet.ibm.com>

Re: [PATCH 1/6] target: Fix QUEUE_FULL + SCSI task attribute handling

rt_complete_task_attr(), and avoid updating SCSI task > attribute related counters for any subsequent calls. > > Also, when a se_cmd is deferred due to ordered tags and executed > via target_restart_delayed_cmds(), set CMD_T_SENT before execution > matching what target_execute_cmd() doe

Re: [PATCH 3/6] target: Fix quiese during transport_write_pending_qf endless loop

hristie <mchri...@redhat.com> > Cc: Hannes Reinecke <h...@suse.com> > Cc: Bryant G. Ly <bryan...@linux.vnet.ibm.com> > Cc: Michael Cyr <mike...@linux.vnet.ibm.com> > Cc: Potnuri Bharat Teja <bha...@chelsio.com> > Cc: Sagi Grimberg <s...@grimberg.m

Re: [PATCH 3/6] target: Fix quiese during transport_write_pending_qf endless loop

> > To address this bug, this patch adds a CMD_T_STOP|CMD_T_ABORTED > check within transport_write_pending_qf() and invokes the > existing se_cmd->t_transport_stop_comp to signal quiese > completion back to __transport_wait_for_tasks(). > > Cc: Mike Christie > Cc: Hannes Re

Re: [PATCH] configfs: Fix race between create_link and configfs_rmdir

Thanks Nic, applied to the configfs-for-next tree. I'm not entirely sure if we should bother adding this to 4.12 or if it hits rarely enough? It hits for us pretty often when we have a GPFS setup with 10 hosts and 1k+ vms. That is how we discovered the bug in the first place. -Bryant

Re: [PATCH] configfs: Fix race between create_link and configfs_rmdir

Thanks Nic, applied to the configfs-for-next tree. I'm not entirely sure if we should bother adding this to 4.12 or if it hits rarely enough? It hits for us pretty often when we have a GPFS setup with 10 hosts and 1k+ vms. That is how we discovered the bug in the first place. -Bryant

Re: [PATCH 2/7] scsi: ibmvscsi_tgt: remove use of class_attrs

The class_attrs pointer is going away and it's not even being used in this driver, so just remove it entirely. Cc: "Bryant G. Ly" <bryan...@linux.vnet.ibm.com> Cc: Michael Cyr <mike...@linux.vnet.ibm.com> Cc: "James E.J. Bottomley" <j...@linux.vn

Re: [PATCH 2/7] scsi: ibmvscsi_tgt: remove use of class_attrs

The class_attrs pointer is going away and it's not even being used in this driver, so just remove it entirely. Cc: "Bryant G. Ly" Cc: Michael Cyr Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Cc: Signed-off-by: Greg Kroah-Hartman --- drivers/sc

Re: [PATCH] target: Fix NULL dereference during LUN lookup + active I/O shutdown

From: Nicholas Bellinger When transport_clear_lun_ref() is shutting down a se_lun via configfs with new I/O in-flight, it's possible to trigger a NULL pointer dereference in transport_lookup_cmd_lun() due to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD

Re: [PATCH] target: Fix NULL dereference during LUN lookup + active I/O shutdown

From: Nicholas Bellinger When transport_clear_lun_ref() is shutting down a se_lun via configfs with new I/O in-flight, it's possible to trigger a NULL pointer dereference in transport_lookup_cmd_lun() due to the fact percpu_ref_get() doesn't do any __PERCPU_REF_DEAD checking before

Re: [PATCH] ibmvscsis: Fix srp_transfer_data fail return code

On 1/9/17 10:47 AM, Greg KH wrote: On Mon, Jan 09, 2017 at 10:21:20AM -0600, Bryant G. Ly wrote: From: "Bryant G. Ly" <b...@us.ibm.com> If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed

Re: [PATCH] ibmvscsis: Fix srp_transfer_data fail return code

On 1/9/17 10:47 AM, Greg KH wrote: On Mon, Jan 09, 2017 at 10:21:20AM -0600, Bryant G. Ly wrote: From: "Bryant G. Ly" If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed the TCE mapping. Thus it

[PATCH] ibmvscsis: Fix srp_transfer_data fail return code

From: "Bryant G. Ly" <b...@us.ibm.com> If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed the TCE mapping. Thus it will loop forever retrying the op that is pretty much guaranteed to fail f

[PATCH] ibmvscsis: Fix srp_transfer_data fail return code

From: "Bryant G. Ly" If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed the TCE mapping. Thus it will loop forever retrying the op that is pretty much guaranteed to fail forever. A better return

Re: linux-next: build warning after merge of the scsi tree

On 9/12/16, 11:15 PM, "Stephen Rothwell" wrote: > Hi James, > > After merging the scsi tree, today's linux-next build (powerpc > allyesconfig) produced this warning: > > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis_rdma':

Re: linux-next: build warning after merge of the scsi tree

On 9/12/16, 11:15 PM, "Stephen Rothwell" wrote: > Hi James, > > After merging the scsi tree, today's linux-next build (powerpc > allyesconfig) produced this warning: > > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis_rdma': >

[PATCH] target: Fix for hang of Ordered task in TCM

Nicholas Bellinger <n...@linux-iscsi.org> Signed-off-by: Bryant G. Ly <bryan...@linux.vnet.ibm.com> --- drivers/target/target_core_internal.h | 1 + drivers/target/target_core_sbc.c | 2 +- drivers/target/target_core_transport.c | 62 +++--- in

[PATCH] target: Fix for hang of Ordered task in TCM

rdered task attribute is sent, target_handle_task_attr sees that dev->simple_cmds is not 0, so it decides it can't execute the command until all the (nonexistent) Simple commands have completed. Reported-by: Michael Cyr Signed-off-by: Nicholas Bellinger Signed-off-by: Bryant G. Ly --- drive

[PATCH 3/3] ibmvscsis: clean up functions

From: bryantly This patch removes forward declarations and re-organizes the functions within the driver. This patch also fixes MAINTAINERS for ibmvscsis. Signed-off-by: bryantly --- MAINTAINERS |4 +-

[PATCH 3/3] ibmvscsis: clean up functions

From: bryantly This patch removes forward declarations and re-organizes the functions within the driver. This patch also fixes MAINTAINERS for ibmvscsis. Signed-off-by: bryantly --- MAINTAINERS |4 +- drivers/scsi/ibmvscsi/ibmvscsis.c | 2709

[PATCH 2/3] ibmvscsis: Addressing Bart's comments

From: bryantly This patch contains cleaning up the code for styling and also addresses Bart's comments. Signed-off-by: bryantly --- MAINTAINERS | 4 +- drivers/scsi/Kconfig | 36 +--

[PATCH 2/3] ibmvscsis: Addressing Bart's comments

From: bryantly This patch contains cleaning up the code for styling and also addresses Bart's comments. Signed-off-by: bryantly --- MAINTAINERS | 4 +- drivers/scsi/Kconfig | 36 +-- drivers/scsi/Makefile | 4 +-

IBM VSCSI Target Driver Initial Patch Sets

This patch series addresses comments by Joe with runing checkpatch with a --strict. It cleans up all the misc styling and removes all the forward declarations. The patch also addresses all of Bart's comments besides the preallocation of buffers before IO starts and the merging of unpack_lun with

IBM VSCSI Target Driver Initial Patch Sets

This patch series addresses comments by Joe with runing checkpatch with a --strict. It cleans up all the misc styling and removes all the forward declarations. The patch also addresses all of Bart's comments besides the preallocation of buffers before IO starts and the merging of unpack_lun with

Re: [PATCH] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

Quoting Bart Van Assche <bart.vanass...@sandisk.com>: On 05/24/2016 06:52 AM, Bryant G. Ly wrote: +config SCSI_IBMVSCSIS + tristate "IBM Virtual SCSI Server support" + depends on PPC_PSERIES && SCSI_SRP && TARGET_CORE + help + Th

Re: [PATCH] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

Quoting Bart Van Assche : On 05/24/2016 06:52 AM, Bryant G. Ly wrote: +config SCSI_IBMVSCSIS + tristate "IBM Virtual SCSI Server support" + depends on PPC_PSERIES && SCSI_SRP && TARGET_CORE + help + This is the IBM POWER

[PATCH] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

drivers/scsi/ibmvscsi/viosrp.h +IBM Power Virtual SCSI Device Target Driver +M: Bryant G. Ly <bryan...@linux.vnet.ibm.com> +L: linux-s...@vger.kernel.org +L: target-de...@vger.kernel.org +S: Supported +F: drivers/scsi/ibmvscsi/ibmvscsis.c +F: drivers/scsi/ibmvs

[PATCH] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

Device Target Driver +M: Bryant G. Ly +L: linux-s...@vger.kernel.org +L: target-de...@vger.kernel.org +S: Supported +F: drivers/scsi/ibmvscsi/ibmvscsis.c +F: drivers/scsi/ibmvscsi/ibmvscsis.h +F: drivers/scsi/libsrp.h +F: drivers/scsi/libsrp.c + IBM Power Virtual

Re: [PATCH] Fix for hang of Ordered task in TCM

Quoting "Nicholas A. Bellinger" : So AFAICT for delayed commands, the above patch ends up skipping these three checks subsequently when doing __target_execute_cmd() directly from target_restart_delayed_cmds(), no..? After pondering this some more, what about moving

Re: [PATCH] Fix for hang of Ordered task in TCM

Quoting "Nicholas A. Bellinger" : So AFAICT for delayed commands, the above patch ends up skipping these three checks subsequently when doing __target_execute_cmd() directly from target_restart_delayed_cmds(), no..? After pondering this some more, what about moving these checks into