Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sun, 2017-04-16 at 23:13 -0600, Logan Gunthorpe wrote: > > > > > I'm still not 100% why do you need a "p2mem device" mind you ... > > Well, you don't "need" it but it is a design choice that I think makes a > lot of sense for the following reasons: > > 1) p2pmem is in fact a device on the

[PATCH] scsi:cxgb4i: update module description

Signed-off-by: Varun Prakash --- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c index 3fb3f57..1076c15 100644 ---

Re: [PATCH 02/25] block: remove the blk_execute_rq return value

On 04/14/2017 02:22 AM, h...@lst.de wrote: > On Thu, Apr 13, 2017 at 08:03:22PM +, Bart Van Assche wrote: >> That blk_execute_rq() call can only be reached if a few lines above 0 was >> assigned to the "error" variable. Since nfsd4_scsi_identify_device() returns >> the value of the "error"

[PATCH v3 2/2] scsi: storvsc: Add support for FC rport.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. The driver also attaches to the FC transport to allow host and port names to be published under /sys/class/fc_host/hostX. Current

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 10:52:29AM -0600, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > helper to instantiate the

[PATCH v3 1/2] scsi: scsi_transport_fc: Add dummy initiator role to rport

This patch allows scsi drivers that expose virturalized fibre channel devices but that do not expose rports to successfully rescan the scsi bus via echo "- - -" > /sys/class/scsi_host/hostX/scan. Drivers can create a pseudo rport and indicate FC_PORT_ROLE_FCP_DUMMY_INITIATOR as the rport's role in

[PATCH v3 0/2] scsi: storvsc: Add support for FC rport

The updated patch set provides a way for drivers ( specifically storvsc in this case ) that expose virturalized fc devices but that do not expose rports to be manually scanned. This is done via creating a pseudo rport in storvsc and a corresponding dummy initiator rport role in the fc transport.

Re: [PATCH] scsi: fc: remove redundant check of an unsigned long being less than zero

On 04/14/2017 06:58 AM, Colin King wrote: > From: Colin Ian King > > The check for an unsigned long being less than zero is always false > so it is a redundant check and can be removed. > > Detected by static analysis with by PVS-Studio > > Signed-off-by: Colin Ian

Re: [PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

On 04/09/2017 07:15 PM, NeilBrown wrote: > > mempool_alloc() cannot fail when passed GFP_NOIO or any > other gfp setting that is permitted to sleep. > So remove this pointless code. > > Signed-off-by: NeilBrown Acked-by: Tyrel Datwyler > --- >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > But is it ? For example take a GPU, does it, in your scheme, need an > additional "p2pmem" child ? Why can't the GPU driver just use some > helper to instantiate the necessary struct pages ? What does having an > actual "struct device" child

[PATCH v2 8/8] scsi: Implement blk_mq_ops.show_rq()

Show the SCSI CDB, .eh_eflags and .result for pending SCSI commands in /sys/kernel/debug/block/*/mq/*/dispatch and */rq_list. Signed-off-by: Bart Van Assche Cc: Martin K. Petersen Cc: James Bottomley

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 9:52 AM, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: >> But is it ? For example take a GPU, does it, in your scheme, need an >> additional "p2pmem" child ? Why can't the GPU driver just use some >> helper to

[PATCH v3 3/4] sd: Make synchronize cache upon shutdown asynchronous

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: Hannes

[PATCH v3 1/4] Introduce scsi_start_queue()

This patch does not change any functionality. Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Hannes Reinecke --- drivers/scsi/scsi_lib.c | 25 +++--

[PATCH v3 0/4] Avoid that __scsi_remove_device() hangs

__scsi_remove_device() hangs if it is waiting for the SYNCHRONIZE CACHE command submitted by the sd driver to finish if the block layer queue is stopped and does not get restarted. This patch series avoids that that hang occurs. Changes compared to v2: - Moved the "stop_disk" assignment after the

[PATCH v3 4/4] Avoid that __scsi_remove_device() hangs

Since scsi_target_unblock() uses starget_for_each_device(), since starget_for_each_device() uses scsi_device_get(), since scsi_device_get() fails after unloading of the LLD kernel module has been started scsi_target_unblock() may skip devices that were affected by scsi_target_block(). Ensure that

[PATCH v3 2/4] Introduce scsi_execute_async()

Move the code for submitting a SCSI command from scsi_execute() into scsi_build_rq(). Introduce scsi_execute_async(). This patch does not change any functionality. Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy

Re: [PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

On 04/15/2017 10:06 AM, Christoph Hellwig wrote: Just add a singlethreaded workqueue for storvsc_handle_error and you'll get serialization for all error handling for free. The problem I am seeing is that many work items can be queued up for the same lun before it goes away. The single

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 11:04 AM, Dan Williams wrote: >> Yes, in this scheme, it needs an additional p2pmem child. Why is that an >> issue? It certainly makes it a lot easier for the user to understand the >> p2pmem memory in the system (through the sysfs tree) and reason about >> the topology and when to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote: > Is it ? Again, you create a "concept" the user may have no idea about, > "p2pmem memory". So now any kind of memory buffer on a device can could > be use for p2p but also potentially a bunch of other things becomes > special and called

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote: > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > helper to instantiate the necessary