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

On Tue, 2017-04-18 at 16:24 -0600, Jason Gunthorpe wrote: > Basically, all this list processing is a huge overhead compared to > just putting a helper call in the existing sg iteration loop of the > actual op.  Particularly if the actual op is a no-op like no-mmu x86 > would use. Yes, I'm leaning

Re: [PATCH] scsi: lpfc: fix potential buffer overflow.

Maurizio Lombardi writes: > This patch fixes a potential buffer overflow in lpfc_nvme_info_show(). Applied to 4.12/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi:cxgb4i: update module description

Varun Prakash writes: Applied to 4.12/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering

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

Colin King writes: > The check for an unsigned long being less than zero is always false so > it is a redundant check and can be removed. Applied to 4.12/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

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

NeilBrown writes: > mempool_alloc() cannot fail when passed GFP_NOIO or any other gfp > setting that is permitted to sleep. So remove this pointless code. Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

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

On Tue, 2017-04-18 at 17:21 -0600, Jason Gunthorpe wrote: > Splitting the sgl is different from iommu batching. > > As an example, an O_DIRECT write of 1 MB with a single 4K P2P page in > the middle. > > The optimum behavior is to allocate a 1MB-4K iommu range and fill it > with the CPU memory.

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

On Tue, 2017-04-18 at 15:22 -0600, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > > > I think this opens an even bigger can of worms.. > > > > No, I don't think it does. You'd only shim when the target page is > > backed by a device, not host memory, and

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

On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote: > I don't follow, when does get_dma_ops() return a p2p aware provider? > It has no way to know if the DMA is going to involve p2p, get_dma_ops > is called with the device initiating the DMA. > > So you'd always return the P2P shim on a

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

On Tue, 2017-04-18 at 14:48 -0600, Logan Gunthorpe wrote: > > ...and that dma_map goes through get_dma_ops(), so I don't see the conflict? > > The main conflict is in dma_map_sg which only does get_dma_ops once but > the sg may contain memory of different types. We can handle that in our

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

On Tue, 2017-04-18 at 12:00 -0600, Jason Gunthorpe wrote: > - All platforms can succeed if the PCI devices are under the same >   'segment', but where segments begin is somewhat platform specific >   knowledge. (this is 'same switch' idea Logan has talked about) We also need to be careful whether

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

On Wed, 2017-04-19 at 00:02 +, Bart Van Assche wrote: > On Tue, 2017-04-18 at 16:56 -0700, James Bottomley wrote: > > Actually, I think 3/3 is wrong. You need to start the queue as > > soon as we see it's blocked and the device has gone into DEL. This > > is safe because DEL ensures

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

On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > > ...and

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

On Tue, 2017-04-18 at 16:56 -0700, James Bottomley wrote: > Actually, I think 3/3 is wrong. You need to start the queue as soon as > we see it's blocked and the device has gone into DEL. This is safe > because DEL ensures nothing ever gets from the generic request function > to queuecommand, so

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

On Tue, 2017-04-18 at 23:47 +, Bart Van Assche wrote: > On Tue, 2017-04-18 at 08:56 -0700, James Bottomley wrote: > > How about this approach. It goes straight to DEL if the device is > > blocked (skipping CANCEL). This means that all the commands issued > > in > > ->shutdown will error in

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

On Tue, 2017-04-18 at 08:56 -0700, James Bottomley wrote: > How about this approach. It goes straight to DEL if the device is > blocked (skipping CANCEL). This means that all the commands issued in > ->shutdown will error in the mid-layer, thus making the removal proceed > without being

[PATCH v3 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 Tue, Apr 18, 2017 at 03:51:27PM -0700, Dan Williams wrote: > > This really seems like much less trouble than trying to wrapper all > > the arch's dma ops, and doesn't have the wonky restrictions. > > I don't think the root bus iommu drivers have any business knowing or > caring about dma

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

On 18/04/17 04:24 PM, Jason Gunthorpe wrote: > Try and write a stacked map_sg function like you describe and you will > see how horrible it quickly becomes. Yes, unfortunately, I have to agree with this statement completely. > Since dma mapping is a performance path we must be careful not to >

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

On Tue, Apr 18, 2017 at 3:56 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:50 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >>> >>> >>> On 18/04/17 04:28 PM, Dan Williams wrote: Unlike the pci bus address

Re: pd: remove bogus check for req->errors

On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > The driver never sets req->errors Reviewed-by: Bart Van Assche

Re: block: add a error_count field to struct request

On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > From: Christoph Hellwig > > This is for the legacy floppy and ataflop drivers that currently abuse > ->errors for this purpose. It's stashed away in a union to not grow > the struct size, the other fields are either used

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

On 18/04/17 04:50 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: >> >> >> On 18/04/17 04:28 PM, Dan Williams wrote: >>> Unlike the pci bus address offset case which I think is fundamental to >>> support since shipping archs do this today,

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

On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memory to user space, and would like to >>

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

On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote: > > > On 18/04/17 04:28 PM, Dan Williams wrote: >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this today, I think it is ok to say >> p2p is restricted to a

Re: blk-mq: remove the error argument to blk_mq_complete_request

On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > Now that we always have a ->complete callback we can remove the direct > call to blk_mq_end_request, as well as the error argument to > blk_mq_complete_request. Hello Christoph, Please add a runtime check that issues a warning early

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

On 18/04/17 04:28 PM, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this today, I think it is ok to say > p2p is restricted to a single sgl that gets to talk to host memory or > a single device. That said, what's

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

On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote: > Unlike the pci bus address offset case which I think is fundamental to > support since shipping archs do this toda But we can support this by modifying those arch's unique dma_ops directly. Eg as I explained, my

Re: scsi: introduce a new result field in struct scsi_request

On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > --- a/block/bsg.c > +++ b/block/bsg.c > @@ -391,13 +391,13 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, > struct sg_io_v4 *hdr, > struct scsi_request *req = scsi_req(rq); > int ret = 0; > > - dprintk("rq

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

On Tue, Apr 18, 2017 at 3:15 PM, Logan Gunthorpe wrote: > > > On 18/04/17 03:36 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe >> wrote: >>> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > I

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

On Tue, Apr 18, 2017 at 03:31:58PM -0600, Logan Gunthorpe wrote: > 1) It means that sg_has_p2p has to walk the entire sg and check every > page. Then map_sg_p2p/map_sg has to walk it again and repeat the check > then do some operation per page. If anyone is concerned about the > dma_map

Re: block: remove the blk_execute_rq return value

On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > diff --git a/drivers/block/paride/pd.c b/drivers/block/paride/pd.c > index b05e151c9b38..82c6d02193ae 100644 > --- a/drivers/block/paride/pd.c > +++ b/drivers/block/paride/pd.c > @@ -747,7 +747,8 @@ static int pd_special_command(struct

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

On 18/04/17 03:36 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe > wrote: >> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: I think this opens an even bigger can of worms.. >>> >>> No, I don't think it does. You'd

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

On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: >> > I think this opens an even bigger can of worms.. >> >> No, I don't think it does. You'd only shim when the target page is >> backed by a

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

On 18/04/17 03:03 PM, Jason Gunthorpe wrote: > What about something more incremental like this instead: > - dma_ops will set map_sg_p2p == map_sg when they are updated to > support p2p, otherwise DMA on P2P pages will fail for those ops. > - When all ops support p2p we remove the if and

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

On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: > > I think this opens an even bigger can of worms.. > > No, I don't think it does. You'd only shim when the target page is > backed by a device, not host memory, and you can figure this out by a > is_zone_device_page()-style lookup.

Re: [PATCH] scsi: lpfc: fix potential buffer overflow.

On 4/18/2017 2:55 AM, Maurizio Lombardi wrote: This patch fixes a potential buffer overflow in lpfc_nvme_info_show(). Signed-off-by: Maurizio Lombardi --- looks fine -- james Signed-off-by: James Smart

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

On Tue, Apr 18, 2017 at 2:03 PM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 12:48:35PM -0700, Dan Williams wrote: > >> > Yes, I noticed this problem too and that makes sense. It just means >> > every dma_ops will probably need to be modified to either

Re: nvme-fc: fix status code handling in nvme_fc_fcpio_done

On 4/18/2017 8:52 AM, Christoph Hellwig wrote: From: Christoph Hellwig nvme_complete_async_event expects the little endian status code including the phase bit, and a new completion handler I plan to introduce will do so as well. Change the status variable into the little endian

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

On Tue, Apr 18, 2017 at 12:48:35PM -0700, Dan Williams wrote: > > Yes, I noticed this problem too and that makes sense. It just means > > every dma_ops will probably need to be modified to either support p2p > > pages or fail on them. Though, the only real difficulty there is that it > > will be

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

On 18/04/17 02:31 PM, Dan Williams wrote: > On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse wrote: >>> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe >>> wrote: On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops

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

On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse wrote: >> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe >> wrote: >> > >> > >> > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> >> Ultimately every dma_ops will need special code to support P2P with >>

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

> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe > wrote: > > > > > > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > >> Ultimately every dma_ops will need special code to support P2P with > >> the special hardware that ops is controlling, so it makes some sense > >> to

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

On 18/04/17 01:48 PM, Jason Gunthorpe wrote: > I think this is why progress on this keeps getting stuck - every > solution is a lot of work. Yup! There's also a ton of work just to get the iomem safety issues addressed. Let alone the dma mapping issues. > You could try to do a dummy mapping /

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

On Tue, Apr 18, 2017 at 01:35:32PM -0600, Logan Gunthorpe wrote: > > Ultimately every dma_ops will need special code to support P2P with > > the special hardware that ops is controlling, so it makes some sense > > to start by pushing the check down there in the first place. This > > advice is

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

On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe wrote: > > > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> Ultimately every dma_ops will need special code to support P2P with >> the special hardware that ops is controlling, so it makes some sense >> to start by pushing

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

On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops will need special code to support P2P with > the special hardware that ops is controlling, so it makes some sense > to start by pushing the check down there in the first place. This > advice is partially motivated by how

[PATCH] target: Add WRITE_VERIFY_16

This patch addresses clients who needs write_verify_16 for large volume groups such as AIX. Signed-off-by: Bryant G. Ly --- drivers/target/target_core_sbc.c | 2 ++ include/scsi/scsi_proto.h| 1 + 2 files changed, 3 insertions(+) diff --git

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

On Tue, Apr 18, 2017 at 12:30:59PM -0600, Logan Gunthorpe wrote: > > - The dma ops provider must be able to tell if source memory is bar > >mapped and recover the pci device backing the mapping. > > Do you mean to say that every dma-ops provider needs to be taught about > p2p backed pages?

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

On Tue, Apr 18, 2017 at 11:00 AM, Jason Gunthorpe wrote: > On Tue, Apr 18, 2017 at 10:27:47AM -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memory to user space, and would

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

On 18/04/17 10:45 AM, Jason Gunthorpe wrote: > From Ben's comments, I would think that the 'first class' support that > is needed here is simply a function to return the 'struct device' > backing a CPU address range. Yes, and Dan's get_dev_pagemap suggestion gets us 90% of the way there. It's

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

On Tue, Apr 18, 2017 at 10:27:47AM -0700, Dan Williams wrote: > > FWIW, RDMA probably wouldn't want to use a p2mem device either, we > > already have APIs that map BAR memory to user space, and would like to > > keep using them. A 'enable P2P for bar' helper function sounds better > > to me. > >

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

On Tue, Apr 18, 2017 at 9:45 AM, Jason Gunthorpe wrote: > On Mon, Apr 17, 2017 at 08:23:16AM +1000, Benjamin Herrenschmidt wrote: > >> Thanks :-) There's a reason why I'm insisting on this. We have constant >> requests for this today. We have hacks in the GPU

Re: RFC: drop the T10 OSD code and its users

As one of those academics that Boaz was talking about, we do use the OSD driver for various research projects including support for OSD in parallel file systems like OrangeFS and Lustre. John. > On Apr 18, 2017, at 12:24 PM, Boaz Harrosh wrote: > > On 04/12/2017 07:01

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

On Mon, Apr 17, 2017 at 08:23:16AM +1000, Benjamin Herrenschmidt wrote: > Thanks :-) There's a reason why I'm insisting on this. We have constant > requests for this today. We have hacks in the GPU drivers to do it for > GPUs behind a switch, but those are just that, ad-hoc hacks in the >

Re: RFC: drop the T10 OSD code and its users

On 04/12/2017 07:01 PM, Christoph Hellwig wrote: Hi Sir Christoph > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and the > other two users (osdblk and exofs) were simple example of it's usage. > I understand

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

On Tue, 2017-04-18 at 08:56 -0700, James Bottomley wrote: > How about this approach. It goes straight to DEL if the device is > blocked (skipping CANCEL). This means that all the commands issued in > ->shutdown will error in the mid-layer, thus making the removal proceed > without being

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

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

On Tue, 2017-04-18 at 16:44 +0200, Benjamin Block wrote: > Hej Bart, > > sry for the late'ish reply, had a long weekend. > > On Thu, Apr 13, 2017 at 12:28:54AM +, Bart Van Assche wrote: > > On Wed, 2017-04-12 at 16:41 +0200, Benjamin Block wrote: > > > On Mon, Apr 10, 2017 at 10:54:01AM

block: add a error_count field to struct request

From: Christoph Hellwig This is for the legacy floppy and ataflop drivers that currently abuse ->errors for this purpose. It's stashed away in a union to not grow the struct size, the other fields are either used by modern drivers for different purposes or the I/O scheduler before

ataflop: switch from req->errors to req->error_count

From: Christoph Hellwig Signed-off-by: Christoph Hellwig --- drivers/block/ataflop.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/block/ataflop.c b/drivers/block/ataflop.c index 2104b1b4ccda..fa69ecd52cb5 100644 ---

pd: remove bogus check for req->errors

From: Christoph Hellwig The driver never sets req->errors --- drivers/block/paride/pd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/block/paride/pd.c b/drivers/block/paride/pd.c index 82c6d02193ae..3b0ab214fe74 100644 ---

blk-mq: remove the error argument to blk_mq_complete_request

From: Christoph Hellwig Now that we always have a ->complete callback we can remove the direct call to blk_mq_end_request, as well as the error argument to blk_mq_complete_request. Signed-off-by: Christoph Hellwig --- block/blk-mq.c| 15

dm rq: don't pass irrelevant error code to blk_mq_complete_request

From: Christoph Hellwig dm never uses rq->errors, so there is no need to pass an error argument to blk_mq_complete_request. Signed-off-by: Christoph Hellwig --- drivers/md/dm-rq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-rq.c

scsi: introduce a new result field in struct scsi_request

From: Christoph Hellwig This passes on the scsi_cmnd result field to users of passthrough requests. Currently we abuse req->errors for this purpose, but that field will go away in its current form. Note that the old IDE code abuses the errors field in very creative ways and stores

block: remove the errors field from struct request

From: Christoph Hellwig Signed-off-by: Christoph Hellwig Acked-by: Roger Pau Monné Reviewed-by: Konrad Rzeszutek Wilk --- block/blk-core.c | 14 +- block/blk-exec.c | 3 +--

mtip32xx: add a status field to struct mtip_cmd

From: Christoph Hellwig Instead of using req->errors, which will go away. Signed-off-by: Christoph Hellwig --- drivers/block/mtip32xx/mtip32xx.c | 16 +--- drivers/block/mtip32xx/mtip32xx.h | 1 + 2 files changed, 10 insertions(+), 7 deletions(-) diff

kill req->errors V2

Currently the request structure has an errors field that is used in various different ways. The oldest drivers use it as an error count, blk-mq and the generic timeout code assume that it holds a Linux errno for block completions, and various drivers use it for internal status values, often

dm mpath: don't check for req->errors

From: Christoph Hellwig We'll get all proper errors reported through ->end_io and ->errors will go away soon. Signed-off-by: Christoph Hellwig --- drivers/md/dm-mpath.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-mpath.c

nbd: don't use req->errors

From: Christoph Hellwig Add a nbd-specific field instead. Signed-off-by: Christoph Hellwig Reviewed-by: Josef Bacik --- drivers/block/nbd.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git

virtio_blk: don't use req->errors

From: Christoph Hellwig Remove passing req->errors (which at that point is always 0) to blk_mq_complete_request, and rely on the virtio status code for the serial number passthrough request. Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn

null_blk: don't pass always-0 req->errors to blk_mq_complete_request

From: Christoph Hellwig Signed-off-by: Christoph Hellwig --- drivers/block/null_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c index f93906ff31e8..24ca85a70fd8 100644 ---

nvme: split nvme status from block req->errors

From: Christoph Hellwig We want our own clearly defined error field for NVMe passthrough commands, and the request errors field is going away in its current form. Just store the status and result field in the nvme_request field from hardirq completion context (using a new helper)

virtio: fix spelling of virtblk_scsi_request_done

From: Christoph Hellwig Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Bart Van Assche --- drivers/block/virtio_blk.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

floppy: switch from req->errors to req->error_count

From: Christoph Hellwig Signed-off-by: Christoph Hellwig --- drivers/block/floppy.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index ce102ec47ef2..60d4c7653178 100644 ---

nvme-fc: fix status code handling in nvme_fc_fcpio_done

From: Christoph Hellwig nvme_complete_async_event expects the little endian status code including the phase bit, and a new completion handler I plan to introduce will do so as well. Change the status variable into the little endian format with the phase bit used in the NVMe CQE to

block: remove the blk_execute_rq return value

From: Christoph Hellwig The function only returns -EIO if rq->errors is non-zero, which is not very useful and lets a large number of callers ignore the return value. Just let the callers figure out their error themselves. Signed-off-by: Christoph Hellwig

swim3: remove (commented out) printing of req->errors

From: Christoph Hellwig Signed-off-by: Christoph Hellwig --- drivers/block/swim3.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c index 61b3ffa4f458..ba4809c9bdba 100644 --- a/drivers/block/swim3.c

nvme: make nvme_error_status private

From: Christoph Hellwig Currently it's used by the lighnvm passthrough ioctl, but we'd like to make it private in preparation of block layer specific error code. Lighnvm already returns the real NVMe status anyway, so I think we can just limit it to returning -EIO for any status

blktrace: remove the unused block_rq_abort tracepoint

From: Christoph Hellwig Signed-off-by: Christoph Hellwig --- include/trace/events/block.h | 44 ++-- kernel/trace/blktrace.c | 9 - 2 files changed, 10 insertions(+), 43 deletions(-) diff --git

xen-blkfront: don't use req->errors

From: Christoph Hellwig xen-blkfron is the last users using rq->errros for passing back error to blk-mq, and I'd like to get rid of that. In the longer run the driver should be moving more of the completion processing into .complete, but this is the minimal change to move forward

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote: > > > On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > > Interesting that you didn't CC any of the maintainers. Could you > > do that in the future please? > > Please read the cover letter. The distribution list for the

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > >

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > Interesting that you didn't CC any of the maintainers. Could you > do that in the future please? Please read the cover letter. The distribution list for the patchset would have been way too large to cc every maintainer (even as limited as it

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

On Tue, 2017-04-18 at 14:58 +0300, Israel Rukshin wrote: > I tested those patches and I got a NULL dereference at sd_sync_cache_done(). > The test is unloading ib_srp while one port is down. > The previous version worked fine. > > From the log: > [ 190.272412] BUG: unable to handle kernel NULL

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

On Tue, 2017-04-18 at 16:44 +0200, Benjamin Block wrote: > I still wonder why we try 'so hard' scheduling a command for a dead > device, but as that seems to be the status quo, and only lacks in the > case where the LLD is already half-way gone, its ok for me too. I mean, > the order is a bit

Re: [PATCH] scsi: lpfc: fix potential buffer overflow.

On Tue, 2017-04-18 at 11:55 +0200, Maurizio Lombardi wrote: > This patch fixes a potential buffer overflow in lpfc_nvme_info_show(). > > Signed-off-by: Maurizio Lombardi > --- > drivers/scsi/lpfc/lpfc_attr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >

Re: [PATCH 17/25] blk-mq: remove the error argument to blk_mq_complete_request

On Tue, Apr 18, 2017 at 04:03:21PM +0100, Roger Pau Monné wrote: > On Thu, Apr 06, 2017 at 05:39:36PM +0200, Christoph Hellwig wrote: > > Now that we always have a ->complete callback we can remove the direct > > call to blk_mq_end_request, as well as the error argument to > >

Re: [PATCH 16/25] xen-blkfront: don't use req->errors

On Tue, Apr 18, 2017 at 04:00:51PM +0100, Roger Pau Monné wrote: > On Thu, Apr 06, 2017 at 05:39:35PM +0200, Christoph Hellwig wrote: > > xen-blkfron is the last users using rq->errros for passing back error to > > blk-mq, and I'd like to get rid of that. In the longer run the driver > > should

Re: [PATCH 17/25] blk-mq: remove the error argument to blk_mq_complete_request

On Thu, Apr 06, 2017 at 05:39:36PM +0200, Christoph Hellwig wrote: > Now that we always have a ->complete callback we can remove the direct > call to blk_mq_end_request, as well as the error argument to > blk_mq_complete_request. > > Signed-off-by: Christoph Hellwig For blkfront:

Re: [PATCH 16/25] xen-blkfront: don't use req->errors

On Thu, Apr 06, 2017 at 05:39:35PM +0200, Christoph Hellwig wrote: > xen-blkfron is the last users using rq->errros for passing back error to > blk-mq, and I'd like to get rid of that. In the longer run the driver > should be moving more of the completion processing into .complete, but > this is

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

Hej Bart, sry for the late'ish reply, had a long weekend. On Thu, Apr 13, 2017 at 12:28:54AM +, Bart Van Assche wrote: > On Wed, 2017-04-12 at 16:41 +0200, Benjamin Block wrote: > > On Mon, Apr 10, 2017 at 10:54:01AM -0700, Bart Van Assche wrote: > > > [ ... ] > > OK, so I take it the

Re: kill req->errors

On Fri, Apr 07, 2017 at 09:11:24AM +0200, Christoph Hellwig wrote: > On Thu, Apr 06, 2017 at 04:00:24PM -0400, Konrad Rzeszutek Wilk wrote: > > You wouldn't have a git tree to easily test it? Thanks. > > git://git.infradead.org/users/hch/block.git request-errors > > Gitweb: > >

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote: > From: Logan Gunthorpe > > Sent: 13 April 2017 23:05 > > Straightforward conversion to the new helper, except due to > > the lack of error path, we have to warn if unmapable memory > > is ever present in the sgl. Interesting that you

RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

From: Logan Gunthorpe > Sent: 13 April 2017 23:05 > Straightforward conversion to the new helper, except due to > the lack of error path, we have to warn if unmapable memory > is ever present in the sgl. > > Signed-off-by: Logan Gunthorpe > --- >

Re: [PATCH] [SCSI] aic7xxx: remove redundant assignment to error

On Tue, Apr 18, 2017 at 12:53:27PM +0100, Colin King wrote: > From: Colin Ian King > > error is initially assigned to ENOENT and a few statements later > is re-assigned to the error return from the call to ahd_wait_seeprom, > hence the initial assignment is redundant

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

On 4/17/2017 8:34 PM, Bart Van Assche wrote: __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

[PATCH] [SCSI] aic7xxx: remove redundant assignment to error

From: Colin Ian King error is initially assigned to ENOENT and a few statements later is re-assigned to the error return from the call to ahd_wait_seeprom, hence the initial assignment is redundant and can be removed. Signed-off-by: Colin Ian King

[PATCH] scsi: lpfc: fix potential buffer overflow.

This patch fixes a potential buffer overflow in lpfc_nvme_info_show(). Signed-off-by: Maurizio Lombardi --- drivers/scsi/lpfc/lpfc_attr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c

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

On Mon, Apr 17, 2017 at 10:01:09AM -0600, Jens Axboe wrote: > Are you respinning this series for 4.12? Yes, I think I got enough feedback by now to resend it. I'll try to get it out today.

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: > This is a single straightforward conversion from kmap to sg_map. > > Signed-off-by: Logan Gunthorpe Acked-by: Daniel Vetter Probably makes sense to merge through some other tree,

  1   2   >