Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Apr 18, 2017 at 10:57:11PM +, Bart Van Assche wrote:
> Both blk-mq and the traditional block layer support a .cmd_size field to
> make the block layer core allocate driver-specific data at the end of struct
> request. Could that mechanism have been used for the error_count field?
It co
On Tue, Apr 18, 2017 at 10:34:20PM +, Bart Van Assche wrote:
> Did you perhaps intend "req->result" instead of "rq->result"?
Yes.
> Did you intend "war" or is that perhaps a typo?
I'll fix the comment.
> > trace_scsi_dispatch_cmd_done(cmd);
> > - blk_mq_complete_request(cmd->request,
On Tue, Apr 18, 2017 at 10:24:15PM +, Bart Van Assche wrote:
> 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/blo
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
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
Varun Prakash writes:
Applied to 4.12/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
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
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
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. T
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 y
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 syst
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 "overrid
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
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 nothing
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 I
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 t
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 t
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 stopped.
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
Cc: Omar Sandoval
Cc: Hannes Reinecke
Cc:
---
drivers/scsi/scsi_lib.c | 26
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 happen
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
>
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 offset case which I think is fundamental to
On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote:
> The driver never sets req->errors
Reviewed-by: Bart Van Assche
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 by modern dri
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, I think it is ok to sa
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
>> > keep using them. A 'enabl
On Tue, Apr 18, 2017 at 3:42 PM, Jason Gunthorpe
wrote:
> 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 uni
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 single sgl that gets to
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 if
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 wro
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 p2p_same_segment_map
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
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 think this opens an even bigger can of worms..
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 performanc
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 p
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 only shim when the target page is
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 device, not host memory, and you can
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 ops->ma
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.
T
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
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 support p2p
>> > pages or fail on them.
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 format with th
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 a
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 will need special code to support P2P wit
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
>> >> the special hardware that ops is control
> 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 the chec
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 / c
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 part
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 the check down there in
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 dma_
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 a/drivers/target/target_core_sbc.c b/drivers/t
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? I
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 like to
>> > keep using them. A 'enab
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 ju
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.
>
> .
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 drivers to do it for
>> GPUs behind a
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 PM, Christoph Hellwig wr
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
> drivers
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 why
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 stopped.
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 happil
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 -0700
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 queing the I/O
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
--- a/drivers/block/ataflop.c
+++ b/dri
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
--- a/drivers/block/paride/pd.c
+++ b/drive
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 +++
drivers/block/loop.c
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 b/drivers/md/dm-rq.c
index
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 all kinds of
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 +--
block/blk-mq.c | 10 +++---
block/blk-timeout.c | 1 -
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 --git a/drivers/block/mtip32
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 overwr
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 a/drivers/block/nbd.c b/drivers/block/nbd.c
index b78f
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 b/drivers/md/dm-mpath.c
index ab559
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
---
drivers/block/virtio_blk.c | 10 +
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
--- a/drivers/block/null_blk.c
+++ b/drivers/bloc
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) and then genera
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 --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index eaf99022
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
--- a/drivers/block/floppy.c
+++ b/drivers/block/
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 fix / enable t
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
Reviewed-by: Johannes Thumshirn
---
From: Christoph Hellwig
Merge blk_mq_ipi_complete_request and blk_mq_stat_add into their only
caller.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 0c19df6
From: Christoph Hellwig
In thruth I've just audited which blk-mq drivers don't currently have a
complete callback, but I think this change is at least borderline useful.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ming Lei
---
drivers/block/loop.c | 30 ++
driver
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
+++ b/drivers/block/swim3.
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 set.
This will
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 a/include/trace/events/block.h b/include/trace
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 for now.
Signe
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 patchs
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
>
> Probably makes sense to merge through some oth
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
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 po
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 screw
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(-)
>
> diff --git a/drivers/sc
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
> > blk_mq_complete_reque
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 be
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:
Acked-by: Roge
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 t
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 problem
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:
>
> http://git.infrad
1 - 100 of 107 matches
Mail list logo
