avoid it with a simple NULL hctx test.
This issue was introduced by:
b32232073e80: blk-mq: fix hang in bt_get()
Tested by hammering mtip32xx with concurrent smartctl/hdparm.
Signed-off-by: Sam Bradshaw
Signed-off-by: Selvan Mani
---
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index
Good catch! But why not put the hctx == NULL check in as a conditional
in bt_get() before running the queue? I can't imagine other cases where
calling blk_mq_run_hw_queue() with hctx == NULL would be a valid scenario.
The change was meant to be broad in scope. A runtime NULL deref is a
. This patch fixes that bug.
An alternative implementation might skip kicking the queue for reserved
tags and go right to io_schedule() but we chose to keep it simple.
Tested by hammering mtip32xx with concurrent smartctl/hdparm.
Signed-off-by: Sam Bradshaw
Signed-off-by: Selvan Mani
---
block/blk
. This patch fixes that bug.
An alternative implementation might skip kicking the queue for reserved
tags and go right to io_schedule() but we chose to keep it simple.
Tested by hammering mtip32xx with concurrent smartctl/hdparm.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
Signed-off-by: Selvan
avoid it with a simple NULL hctx test.
This issue was introduced by:
b32232073e80: blk-mq: fix hang in bt_get()
Tested by hammering mtip32xx with concurrent smartctl/hdparm.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
Signed-off-by: Selvan Mani sm...@micron.com
---
diff --git a/block/blk-mq
Good catch! But why not put the hctx == NULL check in as a conditional
in bt_get() before running the queue? I can't imagine other cases where
calling blk_mq_run_hw_queue() with hctx == NULL would be a valid scenario.
The change was meant to be broad in scope. A runtime NULL deref is a
The prot_buf pointer passed to the generate/verify functions is
incorrect for the second and subsequent range, making it impossible
to verify the guard tag. The patch correctly increments the prot_buf
pointer by the tuple size for each pass.
Signed-off-by: Sam Bradshaw
---
diff --git a/block
The prot_buf pointer passed to the generate/verify functions is
incorrect for the second and subsequent range, making it impossible
to verify the guard tag. The patch correctly increments the prot_buf
pointer by the tuple size for each pass.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Wednesday, January 07, 2015 4:19 PM
> To: Sam Bradshaw (sbradshaw)
> Cc: Martin K. Petersen; ax...@kernel.dk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] block:
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Wednesday, January 07, 2015 3:43 PM
> To: Sam Bradshaw (sbradshaw)
> Cc: Martin K. Petersen; ax...@kernel.dk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] block:
> Sam> Any particular objection to this patch? It would be nice if the
> Sam> kernel supported PI on block sizes other than just 512 bytes.
>
> I never saw the patch. Did you CC: me on it?
Yes, you were CC: on the original. Could you take a peek at the patch
and give me feedback?
On 12/18/2014 04:11 PM, Sam Bradshaw wrote:
The seed value passed to the blk integrity metadata generation function
was wrong depending on the device block size (interval) and how many
blocks comprised the bvec. This patch converts the seed to 'interval'
units and increments it correctly
On 12/18/2014 04:11 PM, Sam Bradshaw wrote:
The seed value passed to the blk integrity metadata generation function
was wrong depending on the device block size (interval) and how many
blocks comprised the bvec. This patch converts the seed to 'interval'
units and increments it correctly
Sam Any particular objection to this patch? It would be nice if the
Sam kernel supported PI on block sizes other than just 512 bytes.
I never saw the patch. Did you CC: me on it?
Yes, you were CC: on the original. Could you take a peek at the patch
and give me feedback?
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Wednesday, January 07, 2015 3:43 PM
To: Sam Bradshaw (sbradshaw)
Cc: Martin K. Petersen; ax...@kernel.dk; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: pass correct seed to integrity
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Wednesday, January 07, 2015 4:19 PM
To: Sam Bradshaw (sbradshaw)
Cc: Martin K. Petersen; ax...@kernel.dk; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: pass correct seed to integrity
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Monday, January 05, 2015 10:45 PM
> To: ax...@fb.com
> Cc: Asai Thambi Samymuthu Pattrayasamy (asamymuthupa); Sam Bradshaw
> (sbradshaw); h...@lst.de; Selvan Mani (smani) [CONT
-Original Message-
From: Nicholas Krause [mailto:xerofo...@gmail.com]
Sent: Monday, January 05, 2015 10:45 PM
To: ax...@fb.com
Cc: Asai Thambi Samymuthu Pattrayasamy (asamymuthupa); Sam Bradshaw
(sbradshaw); h...@lst.de; Selvan Mani (smani) [CONT - Type 2];
agord...@redhat.com
/ type1 PI) sector size.
Signed-off-by: Sam Bradshaw
Signed-off-by: Selvan Mani
---
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index 5cbd5d9..7114040 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -219,20 +219,22 @@ static int bio_integrity_process(struct bio *bio
/ type1 PI) sector size.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
Signed-off-by: Selvan Mani sm...@micron.com
---
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index 5cbd5d9..7114040 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -219,20 +219,22 @@ static int
een irq_workers_active and unal_qdepth.
With some workload and topology configurations, I'm seeing ~1.5%
throughput improvement in small block random read benchmarks as well
as improved latency std. dev.
Signed-off-by: Sam Bradshaw
---
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip3
irq_workers_active and unal_qdepth.
With some workload and topology configurations, I'm seeing ~1.5%
throughput improvement in small block random read benchmarks as well
as improved latency std. dev.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
---
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers
both
mtip_port and driver_data allocations for consistency.
Signed-off-by: Sam Bradshaw
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 624e9d9..f55e3e5 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3116,7
On 03/13/2014 02:02 PM, Jens Axboe wrote:
> On 03/13/2014 03:09 PM, Sam Bradshaw wrote:
>> This patch fixes 2 issues in the fast completion path:
>> 1) Possible double completions / double dma_unmap_sg() calls due to lack
>> of atomicity in the check and subsequent dereferen
constraining workaround for p420m devices.
Fixed by checking if IO is unaligned and using proper semaphore if so.
Bumped version to indicate presence of these fixes.
Signed-off-by: Sam Bradshaw
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index b2012b7
constraining workaround for p420m devices.
Fixed by checking if IO is unaligned and using proper semaphore if so.
Bumped version to indicate presence of these fixes.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx
On 03/13/2014 02:02 PM, Jens Axboe wrote:
On 03/13/2014 03:09 PM, Sam Bradshaw wrote:
This patch fixes 2 issues in the fast completion path:
1) Possible double completions / double dma_unmap_sg() calls due to lack
of atomicity in the check and subsequent dereference of the upper layer
both
mtip_port and driver_data allocations for consistency.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 624e9d9..f55e3e5 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx
()
calls during surprise removal and/or timeout conditions.
Jens: note that this patch also fixes a regression in the unaligned
workaround implementation that was introduced by the SRSI patch.
Signed-off-by: Sam Bradshaw
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx
()
calls during surprise removal and/or timeout conditions.
Jens: note that this patch also fixes a regression in the unaligned
workaround implementation that was introduced by the SRSI patch.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers
> On 2014-02-26 11:29, Christoph Hellwig wrote:
> > Hi all,
> >
> > with blk-mq stabilizing in mainline and Jens using mtip32xx as tje
> major
> > example drivers in the past is there any progress on getting the
> > conversion finished and merged?
>
> I'll pick up the pieces as soon as I get
On 2014-02-26 11:29, Christoph Hellwig wrote:
Hi all,
with blk-mq stabilizing in mainline and Jens using mtip32xx as tje
major
example drivers in the past is there any progress on getting the
conversion finished and merged?
I'll pick up the pieces as soon as I get back and can test
and SGL. The two pages allow up to 504 SGL segments.
Signed-off-by: Sam Bradshaw
Signed-off-by: Asai Thambi S P
---
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 050c712..ae46bfd 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/
. The two pages allow up to 504 SGL segments.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
Signed-off-by: Asai Thambi S P asamymuth...@micron.com
---
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 050c712..ae46bfd 100644
--- a/drivers/block/mtip32xx
version number to reflect this capability.
Signed-off-by: Sam Bradshaw
Signed-off-by: Asai Thambi S P
---
drivers/block/mtip32xx/mtip32xx.c | 16 ++--
drivers/block/mtip32xx/mtip32xx.h |2 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/block/mtip32xx
version number to reflect this capability.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
Signed-off-by: Asai Thambi S P asamymuth...@micron.com
---
drivers/block/mtip32xx/mtip32xx.c | 16 ++--
drivers/block/mtip32xx/mtip32xx.h |2 +-
2 files changed, 15 insertions(+), 3 deletions
Stacking drivers may append bvecs to existing bio's, resulting
in non-zero bi_idx conditions. This patch counts the loops of
bio_for_each_segment() rather than inheriting the bi_idx value
to pass as a segment count to the hardware submission routine.
Signed-off-by: Sam Bradshaw
---
diff --git
An open file-handle to one or more of the driver exported debugfs
nodes causes raciness in recursive removal during module unload;
sometimes a stale parent dentry is dereferenced when more than 1
pci device is present.
Signed-off-by: Sam Bradshaw
---
diff --git a/drivers/block/mtip32xx
An open file-handle to one or more of the driver exported debugfs
nodes causes raciness in recursive removal during module unload;
sometimes a stale parent dentry is dereferenced when more than 1
pci device is present.
Signed-off-by: Sam Bradshaw
---
diff --git a/drivers/block/mtip32xx
An open file-handle to one or more of the driver exported debugfs
nodes causes raciness in recursive removal during module unload;
sometimes a stale parent dentry is dereferenced when more than 1
pci device is present.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
---
diff --git a/drivers
An open file-handle to one or more of the driver exported debugfs
nodes causes raciness in recursive removal during module unload;
sometimes a stale parent dentry is dereferenced when more than 1
pci device is present.
Signed-off-by: Sam Bradshaw sbrads...@micron.com
---
diff --git a/drivers
Stacking drivers may append bvecs to existing bio's, resulting
in non-zero bi_idx conditions. This patch counts the loops of
bio_for_each_segment() rather than inheriting the bi_idx value
to pass as a segment count to the hardware submission routine.
Signed-off-by: Sam Bradshaw sbrads
> On Fri, Apr 12 2013, Asai Thambi S P wrote:
> >
> > Temporarily disabling TRIM support until TRIM related issues
> > are addressed in the firmware.
>
> How serious is this? We do have released kernels out there with the
> driver, you might want to consider a stable backport too.
It's a
On Fri, Apr 12 2013, Asai Thambi S P wrote:
Temporarily disabling TRIM support until TRIM related issues
are addressed in the firmware.
How serious is this? We do have released kernels out there with the
driver, you might want to consider a stable backport too.
It's a performance
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, October 08, 2012 12:13 AM
> To: Sam Bradshaw (sbradshaw)
> Cc: Jens Axboe; linux-kernel@vger.kernel.org
> Subject: re: block: Add driver for Micron RealSSD pcie flash cards
>
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Monday, October 08, 2012 12:13 AM
To: Sam Bradshaw (sbradshaw)
Cc: Jens Axboe; linux-kernel@vger.kernel.org
Subject: re: block: Add driver for Micron RealSSD pcie flash cards
Hello Sam Bradshaw
46 matches
Mail list logo
