Hi Russell,
On 2017/2/15 3:34, Russell King - ARM Linux wrote:
On Tue, Feb 14, 2017 at 09:18:43AM -0700, Jens Axboe wrote:
The current situation seems like a bit of a mess. Why don't you have two
entry points, one for DMA and one for PIO. If the caller doesn't know if
he can use DMA, he'd bette
When a new disk shows up, sysfs queue directory is created before elevator
is registered. This allows a user to attempt a scheduler switch even though
the initial registration hasn't completed yet.
In one scenario, blk_register_queue() calls elv_register_queue() and
right before cfq_registered_que
On 02/14/2017 05:29 PM, Scott Bauer wrote:
> The IOC_OPAL_ACTIVATE_LSP took the wrong strcure which would
> give us the wrong size when using _IOC_SIZE, switch it to the
> right structure.
Applied 1-3, thanks.
--
Jens Axboe
On Wed, Feb 15, 2017 at 12:01 AM, Christoph Hellwig wrote:
> On Tue, Feb 14, 2017 at 09:04:26AM +0800, Ming Lei wrote:
>> On Mon, Feb 13, 2017 at 9:46 PM, Christoph Hellwig
>> wrote:
>> > On Fri, Feb 10, 2017 at 06:56:13PM +0800, Ming Lei wrote:
>> >> md still need bio clone(not the fast version
Signed-off-by: Scott Bauer
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e325373..b983b25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11094,7 +11094,7 @@ SECURE ENCRYPTING DEVICE (SED) OPAL DRIVER
M: Scott Bauer
M:
When CONFIG_KASAN is enabled, compilation fails:
block/sed-opal.c: In function 'sed_ioctl':
block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than
2048 bytes [-Werror=frame-larger-than=]
Moved all the ioctl structures off the stack and dynamically allocate
using _IOC_SIZE()
The IOC_OPAL_ACTIVATE_LSP took the wrong strcure which would
give us the wrong size when using _IOC_SIZE, switch it to the
right structure.
Fixes: 058f8a2 ("Include: Uapi: Add user ABI for Sed/Opal")
Signed-off-by: Scott Bauer
---
include/uapi/linux/sed-opal.h | 2 +-
1 file changed, 1 insertio
On Tue, Feb 14, 2017 at 09:18:43AM -0700, Jens Axboe wrote:
> The current situation seems like a bit of a mess. Why don't you have two
> entry points, one for DMA and one for PIO. If the caller doesn't know if
> he can use DMA, he'd better call the PIO variant. Either that, or audit
> all callers a
And switch all callers to use scsi_execute instead.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/device_handler/scsi_dh_alua.c | 16 ++--
drivers/scsi/device_handler/scsi_dh_emc.c | 7 +++
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 10 --
drivers/scsi/device_h
It's a tiny structure that can be allocated on the stack, don't
complicate the code by making it optional.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/osd/osd_uld.c | 3 ++-
drivers/scsi/scsi_ioctl.c | 3 ++-
drivers/scsi/scsi_lib.c| 14 ++
3 files changed, 6 insertions(
Hi all,
this series is on top of the scsi_request changes in Jens' tree and
further improves the handling of the sense buffer.
The first patch prevents any possibily of reusing stale sense codes
in sense headers, and is a bug fix that we should probably get into
the block tree ASAP.
The rest cle
This gives us a clear state even if a command didn't return sense data.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_common.c b/drivers/scsi/scsi_common.c
index b1383a71400e..a75673bb82b3
All but one caller want the decoded sense header, so offer the existing
__scsi_execute helper as the public scsi_execute API to simply the
callers.
Signed-off-by: Christoph Hellwig
---
drivers/ata/libata-scsi.c | 12 --
drivers/scsi/cxlflash/superpipe.c | 8 +++
drivers/scsi
Remove bogus evaluations of retval and sshdr when the device is offline,
and fix a possible NULL pointer dereference by allocating the 8 byte
sized sense header on stack.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 25 +++--
1 file changed, 11 insertions(+), 14 d
Add a sshdr argument to __scsi_execute so that we can decode the sense
data directly into the sense header instead of needing a copy of it.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git
On Thu, Feb 09 2017 at 4:25pm -0500,
Kent Overstreet wrote:
> On Wed, Feb 08, 2017 at 11:34:07AM -0500, Mike Snitzer wrote:
> > On Tue, Feb 07 2017 at 11:58pm -0500,
> > Kent Overstreet wrote:
> >
> > > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> > > > On Mon 2017-02-06 17:
On Thu, 9 Feb 2017, Kent Overstreet wrote:
> On Wed, Feb 08, 2017 at 11:34:07AM -0500, Mike Snitzer wrote:
> > On Tue, Feb 07 2017 at 11:58pm -0500,
> > Kent Overstreet wrote:
> >
> > > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote:
> > > > On Mon 2017-02-06 17:49:06, Kent Overs
> I tested today's linux-next (next-20170214) + the 2 patches just now and got
> a weird result:
> sometimes the VM stills hung with a new calltrace (BUG: spinlock bad
> magic) , but sometimes the VM did boot up despite the new calltrace!
>
> Attached is the log of a &qu
On 02/14/2017 02:17 AM, Ulf Hansson wrote:
> +Russell, Jens, Christoph, linux-block (asking for help in review)
>
> On 7 February 2017 at 01:54, Shawn Lin wrote:
>> It's fine if the host driver use PIO mode to transfer the
>> vmalloc area buffer but not for DMA mode. The sdio APIs haven't
>> prov
On Tue, Feb 14, 2017 at 09:04:26AM +0800, Ming Lei wrote:
> On Mon, Feb 13, 2017 at 9:46 PM, Christoph Hellwig wrote:
> > On Fri, Feb 10, 2017 at 06:56:13PM +0800, Ming Lei wrote:
> >> md still need bio clone(not the fast version) for behind write,
> >> and it is more efficient to use bio_clone_bi
On Tue, Feb 14, 2017 at 11:29:03PM +0800, Ming Lei wrote:
> Firstly bio_clone_mddev() is used in raid normal I/O and isn't
> in resync I/O path.
>
> Secondly all the direct access to bvec table in raid happens on
> resync I/O except for write behind of raid1, in which we still
> use bio_clone() fo
suppose I don't need to test the 2 patches on the latest linux-next repo.
>
> I'd love a test on that repo actually. We had a few other for sense
> handling since then I think.
I tested today's linux-next (next-20170214) + the 2 patches just now and got
a weird r
> Il giorno 14 feb 2017, alle ore 16:16, Jens Axboe ha
> scritto:
>
> On 02/14/2017 01:14 AM, Paolo Valente wrote:
>>
>>> Il giorno 14 feb 2017, alle ore 00:10, Jens Axboe ha
>>> scritto:
>>>
>>> On 02/13/2017 03:28 PM, Jens Axboe wrote:
On 02/13/2017 03:09 PM, Omar Sandoval wrote:
>>>
On 02/14/2017 08:28 AM, Ming Lei wrote:
> Hi,
>
> This patches replaces bio_clone() with bio_fast_clone() in
> bio_clone_mddev() because:
>
> 1) bio_clone_mddev() is used in raid normal I/O and isn't in
> resync I/O path, and all the direct access to bvec table in
> raid happens on resync I/O onl
The current behaviour is to fall back to allocate
bio from 'fs_bio_set', that isn't a correct way
because it might cause deadlock.
So this patch simply return failure if mddev->bio_set
can't be created.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
drivers/md/md.c | 5 -
1 fil
mddev is never NULL and neither is ->bio_set, so
remove the check.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
drivers/md/md.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index b5e2adf3493b..6cd96fde2a67 100644
--- a/drivers/md/md.c
+++
Firstly bio_clone_mddev() is used in raid normal I/O and isn't
in resync I/O path.
Secondly all the direct access to bvec table in raid happens on
resync I/O except for write behind of raid1, in which we still
use bio_clone() for allocating new bvec table.
So this patch replaces bio_clone() with
Write behind need to replace pages in bio's bvecs, and we have
to clone a fresh bio with new bvec table, so use the introduced
bio_clone_bioset_partial() for it.
For other bio_clone_mddev() cases, we will use fast clone since
they don't need to touch bvec table.
Reviewed-by: Christoph Hellwig
Si
md still need bio clone(not the fast version) for behind write,
and it is more efficient to use bio_clone_bioset_partial().
The idea is simple and just copy the bvecs range specified from
parameters.
Reviewed-by: Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
block/bio.c |
Hi,
This patches replaces bio_clone() with bio_fast_clone() in
bio_clone_mddev() because:
1) bio_clone_mddev() is used in raid normal I/O and isn't in
resync I/O path, and all the direct access to bvec table in
raid happens on resync I/O only except for write behind of raid1.
Write behind is trea
On 02/14/2017 01:14 AM, Paolo Valente wrote:
>
>> Il giorno 14 feb 2017, alle ore 00:10, Jens Axboe ha
>> scritto:
>>
>> On 02/13/2017 03:28 PM, Jens Axboe wrote:
>>> On 02/13/2017 03:09 PM, Omar Sandoval wrote:
On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote:
> If, at boo
On 02/13/2017 11:58 PM, Hannes Reinecke wrote:
> On 02/13/2017 11:28 PM, Jens Axboe wrote:
>> On 02/13/2017 03:09 PM, Omar Sandoval wrote:
>>> On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote:
If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq,
or, viceve
On Tue, Feb 14, 2017 at 02:46:41PM +, Dexuan Cui wrote:
> > From: h...@lst.de [mailto:h...@lst.de]
> > Sent: Tuesday, February 14, 2017 22:29
> > To: Dexuan Cui
> > Subject: Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock
> > when scheduling workqueue elements")
> >
> > Ok
> From: h...@lst.de [mailto:h...@lst.de]
> Sent: Tuesday, February 14, 2017 22:29
> To: Dexuan Cui
> Subject: Re: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock
> when scheduling workqueue elements")
>
> Ok, thanks for testing. Can you try the patch below? It fixes a
> clear pr
Ok, thanks for testing. Can you try the patch below? It fixes a
clear problem which was partially papered over before the commit
you bisected to, although it can't explain why blk-mq still works.
>From e4a66856fa2d92c0298000de658365f31bea60cd Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Dat
> From: h...@lst.de [mailto:h...@lst.de]
>
> Hi Dexuan,
>
> can you try the hack below for now? I disable the TUR call from
> sd_check_events, which I think your VM is hanging on. The checks
> it does on the sense data look a bit fishy, but so far I've not
> identified a possible root cause.
>
Hi Dexuan,
can you try the hack below for now? I disable the TUR call from
sd_check_events, which I think your VM is hanging on. The checks
it does on the sense data look a bit fishy, but so far I've not
identified a possible root cause.
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index
Jens,
My git-send-email script was using the wrong set of destination email
addresses for this patch. This should go to linux-scsi and Martin.
Resending.
My apologies about the noise.
Best regards.
On 2/14/17 21:42, Damien Le Moal wrote:
> Commit "mpt3sas: Force request partial completion align
Commit "mpt3sas: Force request partial completion alignment" was not
considering the case of REQ_TYPE_FS commands not operating on sector
size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned partial
replies). This could result is incorrectly retrying (forever) those
commands.
Move the partial c
+Russell, Jens, Christoph, linux-block (asking for help in review)
On 7 February 2017 at 01:54, Shawn Lin wrote:
> It's fine if the host driver use PIO mode to transfer the
> vmalloc area buffer but not for DMA mode. The sdio APIs haven't
> provide the capability to tell the caller whether it wil
On 02/14/2017 10:00 AM, Damien Le Moal wrote:
> Commit "mpt3sas: Force request partial completion alignment" was not
> considering the case of REQ_TYPE_FS commands not operating on sector
> size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned partial
> replies). This could result is incorrectly
Commit "mpt3sas: Force request partial completion alignment" was not
considering the case of REQ_TYPE_FS commands not operating on sector
size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned partial
replies). This could result is incorrectly retrying (forever) those
commands.
Move the partial c
> + unsigned int sector_sz = SCpnt->device->sector_size;
Can you spell out size?
> + /*
> + * In case of bogus fw or device, we could end up having
> + * unaligned partial completion. Check this here.
> + */
> + resid = scsi_get_resid(SCpnt);
> + if (SCpnt->request-
Reviewed-by: Christoph Hellwig
Let's get it in ASAP as well.
Reviewed-by: Christoph Hellwig
Let's get this one in ASAP while waiting for a respin of the KASAN
fix.
On Mon, Feb 13, 2017 at 09:15:10AM -0700, Scott Bauer wrote:
> esOn Mon, Feb 13, 2017 at 09:11:09AM -0700, Scott Bauer wrote:
> > Signed-off-by: Scott Bauer
> > ---
> > block/sed-opal.c | 6 --
> > drivers/nvme/host/core.c | 3 ++-
> > include/linux/sed-opal.h | 4 ++--
> > 3 files ch
> Il giorno 14 feb 2017, alle ore 00:10, Jens Axboe ha
> scritto:
>
> On 02/13/2017 03:28 PM, Jens Axboe wrote:
>> On 02/13/2017 03:09 PM, Omar Sandoval wrote:
>>> On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote:
If, at boot, a legacy I/O scheduler is chosen for a device usin
Commit "mpt3sas: Force request partial completion alignment" was not
considering the case of REQ_TYPE_FS commands not operating on sector
size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned partial
replies). This could result is incorrectly retrying (forever) those
commands.
Move the partial c
48 matches
Mail list logo
