https://bugzilla.kernel.org/show_bug.cgi?id=198689
Li Ning (yzlin...@foxmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolut
On Wed, May 23, 2018 at 02:19:30PM +0200, Christoph Hellwig wrote:
> NVMe always completes the request before returning from ->timeout, either
> by polling for it, or by disabling the controller. Return BLK_EH_DONE so
> that the block layer doesn't even try to complete it again.
>
> Signed-off-by
On 2018/5/23 17:24, Sebastian Andrzej Siewior wrote:
On 2018-05-23 09:46:30 [+0100], John Garry wrote:
On 22/05/2018 18:31, Sebastian Andrzej Siewior wrote:
On 2018-05-18 14:31:27 [+0100], John Garry wrote:
On 04/05/2018 15:50, Sebastian Andrzej Siewior wrote:
Since commit 312d3e56119a ("[S
Would anyone please take a look at this ?
Thanks in advance
Jianchao
On 05/23/2018 11:55 AM, jianchao.wang wrote:
>
>
> Hi all
>
> Our customer met a panic triggered by BUG_ON in blk_finish_request.
>>From the dmesg log, the BUG_ON was triggered after command abort occurred
>>many times.
> Th
On 5/23/2018 5:32 PM, Bjorn Helgaas wrote:
>
> The crash seems to indicate that the hpsa device attempted a DMA after
> we cleared the Root Port's PCI_COMMAND_MASTER, which means
> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> shutdown methods don't disable device DMA, so
[-cc Gabriele (invalid email address)]
[+cc Don, esc.storagedev, linux-scsi since hpsa is involved]
Background for newcomers:
Ryan reported a panic on shutdown/reboot [1] on DL360 Gen9. I think
the problem is that the shutdown path clears PCI_COMMAND_MASTER on
the Root Port leading to an h
On 05/23/2018 02:22 PM, Jens Axboe wrote:
> On 5/23/18 3:20 PM, Randy Dunlap wrote:
>> On 05/23/2018 02:14 PM, Jens Axboe wrote:
>>> On 5/23/18 2:52 PM, Kees Cook wrote:
On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>> On Wed, May 23
On 5/23/18 3:20 PM, Randy Dunlap wrote:
> On 05/23/2018 02:14 PM, Jens Axboe wrote:
>> On 5/23/18 2:52 PM, Kees Cook wrote:
>>> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
On 5/23/18 8:25 AM, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
>>>
On 05/23/2018 02:14 PM, Jens Axboe wrote:
> On 5/23/18 2:52 PM, Kees Cook wrote:
>> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
>>> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
>> Should I move to code to a new drivers/scs
On Wed, May 23, 2018 at 2:06 PM, Martin K. Petersen
wrote:
>
> Kees,
>
>> obj-$(CONFIG_SCSI) += scsi/
>>
>> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's
>> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll
>> still need to move the code from dr
On 5/23/18 2:52 PM, Kees Cook wrote:
> On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
>> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to
> drivers/scsi/
On Wed, May 23, 2018 at 1:25 AM, Sergei Shtylyov
wrote:
> Hello!
>
> On 5/22/2018 9:15 PM, Kees Cook wrote:
>
>> To avoid introducing problems like those fixed in commit f7068114d45e
>> ("sr: pass down correctly sized SCSI sense buffer"), this creates a macro
>> wrapper for scsi_execute() that ver
Kees,
> obj-$(CONFIG_SCSI) += scsi/
>
> So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's
> scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll
> still need to move the code from drivers/scsi/ to block/. Is this
> okay?
The reason this sucks is that
On Wed, May 23, 2018 at 7:31 AM, Jens Axboe wrote:
> On 5/23/18 8:25 AM, Christoph Hellwig wrote:
>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
Should I move to code to a new drivers/scsi/scsi_sense.c and add it to
drivers/scsi/Makefile as:
obj-$(CONFIG_BLK_SCS
From: Ganesh Goudar
Date: Wed, 23 May 2018 20:02:58 +0530
> MDI Port Capabilities bit definitions were inconsistent with
> regard to the MDI enum values. 2 bits used to define MDI in
> the port capabilities are not really separable, it's a 2-bit
> field with 4 different values. Change the port ca
From: Ganesh Goudar
Date: Wed, 23 May 2018 20:03:33 +0530
> trigger an L1 configure operation when a transceiver module
> is inserted in order to cause current "sticky" options like
> Requested Forward Error Correction to be reapplied.
>
> Signed-off-by: Casey Leedom
> Signed-off-by: Ganesh Gou
On Tue, May 22, 2018 at 09:51:38AM +0530, Sayali Lokhande wrote:
> From: Subhash Jadavani
>
> UFS host supplies the reference clock to UFS device and UFS device
> specification allows host to provide one of the 4 frequencies (19.2 MHz,
> 26 MHz, 38.4 MHz, 52 MHz) for reference clock. Host should
Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>>
>>
>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>>> It's been many years, but back in the day the program writing the cd
>>> would eject the disc once done. This of course forces a reload of
>>> the to
On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>
>
> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>> It's been many years, but back in the day the program writing the cd
>> would eject the disc once done. This of course forces a reload of
>> the toc and clearing of the flag. What program is this? Se
trigger an L1 configure operation when a transceiver module
is inserted in order to cause current "sticky" options like
Requested Forward Error Correction to be reapplied.
Signed-off-by: Casey Leedom
Signed-off-by: Ganesh Goudar
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 26 +
MDI Port Capabilities bit definitions were inconsistent with
regard to the MDI enum values. 2 bits used to define MDI in
the port capabilities are not really separable, it's a 2-bit
field with 4 different values. Change the port capability bit
definitions to be "AUTO" and "STRAIGHT" in order to get
On 5/23/18 8:25 AM, Christoph Hellwig wrote:
> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to
>>> drivers/scsi/Makefile as:
>>>
>>> obj-$(CONFIG_BLK_SCSI_REQUEST)+= scsi_sense.o
>>>
>>> Every place I want to
On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote:
> > Should I move to code to a new drivers/scsi/scsi_sense.c and add it to
> > drivers/scsi/Makefile as:
> >
> > obj-$(CONFIG_BLK_SCSI_REQUEST)+= scsi_sense.o
> >
> > Every place I want to use the code is already covered by
> > CONFI
On Wed, May 23, 2018 at 02:19:40PM +0200, Christoph Hellwig wrote:
> -static void hctx_unlock(struct blk_mq_hw_ctx *hctx, int srcu_idx)
> - __releases(hctx->srcu)
> -{
> - if (!(hctx->flags & BLK_MQ_F_BLOCKING))
> - rcu_read_unlock();
> - else
> - srcu_read_unloc
On 5/22/18 5:49 PM, Kees Cook wrote:
> On Tue, May 22, 2018 at 4:42 PM, Jens Axboe wrote:
>> On May 22, 2018, at 5:31 PM, Kees Cook wrote:
>>>
On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>> On Tue, May 22, 2018 at 01:09:41PM -06
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
From: Keith Busch
The block layer had been setting the state to in-flight prior to updating
the timer. This is the wrong order since the timeout handler could observe
the in-flight state with the older timeout, believing the request had
expired w
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
Documentation/scsi/scsi_eh.txt | 11 ---
block/blk-mq.c | 3 ---
block/blk-timeout.c| 3 ---
include/linux/blkdev.h | 1 -
4 files changed, 18 deletions(-)
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
libiscsi is the only SCSI code that return BLK_EH_HANDLED, thus trying to
bypass the normal SCSI EH code. We are going to remove this return value
at the block layer, and at least from a quick look it doesn't look too
harmful to try to send an abo
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
include/linux/blkdev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3d9d4da4dedd..3815d9dcfbe0 100644
--- a/include/linux/blkd
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
[While this keeps existing behavior it seems to
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
NVMe always completes the request before returning from ->timeout, either
by polling for it, or by disabling the controller. Return BLK_EH_DONE so
that the block layer doesn't even try to complete it again.
Signed-off-by: Christoph Hellwig
---
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
The BLK_EH_NOT_HANDLED implies nothing happen, but very often that
is not what is happening - instead the driver already completed the
command. Fix the symbolic name to reflect that a little better.
Signed-off-by: Christoph Hellwig
---
Documen
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
As far as I can tell this function can't even be called any more, given
that ATA implements its own eh_strategy_handler with ata_scsi_error, which
never calls ->eh_timed_out.
Signed-off-by: Christoph Hellwig
---
drivers/ata/libata-eh.c | 51 ---
On 05/23/2018 02:19 PM, Christoph Hellwig wrote:
Hi all,
this series removes the BLK_EH_HANDLED return value, and instead places
responsibility of timed out commands entirely on the drivers. Except
for some odd layering vilations in libiscsi this actually is
surprisingly simple. The last two p
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG N
From: Keith Busch
This patch simplifies the timeout handling by relying on the request
reference counting to ensure the iterator is operating on an inflight
and truly timed out request. Since the reference counting prevents the
tag from being reallocated, the block layer no longer needs to preven
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 8c7b1803b7e9..592bab689f8e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -747,22 +747,16 @@ EXPORT_SYMBOL(blk
Signed-off-by: Christoph Hellwig
---
Documentation/scsi/scsi_eh.txt | 11 ---
block/blk-mq.c | 3 ---
block/blk-timeout.c| 3 ---
include/linux/blkdev.h | 1 -
4 files changed, 18 deletions(-)
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentat
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
[While this keeps existing behavior it seems to mismatch the comment,
maintainers please chime in!
Signed-off-by: Christoph Hellwig
---
include/linux/blkdev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3d9d4da4dedd..3815d9dcfbe0 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -337,8 +337,8 @@
libiscsi is the only SCSI code that return BLK_EH_HANDLED, thus trying to
bypass the normal SCSI EH code. We are going to remove this return value
at the block layer, and at least from a quick look it doesn't look too
harmful to try to send an abort for these cases, especially as the first
one sho
From: Keith Busch
The block layer had been setting the state to in-flight prior to updating
the timer. This is the wrong order since the timeout handler could observe
the in-flight state with the older timeout, believing the request had
expired when in fact it is just getting started.
Signed-off
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_transport_fc.c | 7 +++
1 file changed
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/block/mtip32xx/mtip32xx.c | 3 ++-
1 file changed, 2
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/block/null_blk.c | 6 --
1 file changed, 4 inser
Hi all,
this series removes the BLK_EH_HANDLED return value, and instead places
responsibility of timed out commands entirely on the drivers. Except
for some odd layering vilations in libiscsi this actually is
surprisingly simple. The last two pathes contain a respin of Keith'
series to refcount
As far as I can tell this function can't even be called any more, given
that ATA implements its own eh_strategy_handler with ata_scsi_error, which
never calls ->eh_timed_out.
Signed-off-by: Christoph Hellwig
---
drivers/ata/libata-eh.c | 51 -
include/linu
NVMe always completes the request before returning from ->timeout, either
by polling for it, or by disabling the controller. Return BLK_EH_DONE so
that the block layer doesn't even try to complete it again.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/pci.c| 14 +-
dri
By completing the request entirely in the driver we can remove the
BLK_EH_HANDLED return value and thus the split responsibility between the
driver and the block layer that has been causing trouble.
Signed-off-by: Christoph Hellwig
---
drivers/block/nbd.c | 7 ---
1 file changed, 4 insertion
The BLK_EH_NOT_HANDLED implies nothing happen, but very often that
is not what is happening - instead the driver already completed the
command. Fix the symbolic name to reflect that a little better.
Signed-off-by: Christoph Hellwig
---
Documentation/scsi/scsi_eh.txt| 4 ++--
block/b
On 2018-05-23 09:46:30 [+0100], John Garry wrote:
> On 22/05/2018 18:31, Sebastian Andrzej Siewior wrote:
> > On 2018-05-18 14:31:27 [+0100], John Garry wrote:
> > > On 04/05/2018 15:50, Sebastian Andrzej Siewior wrote:
> > > > Since commit 312d3e56119a ("[SCSI] libsas: remove ata_port.lock
> > > >
Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
> It's been many years, but back in the day the program writing the cd
> would eject the disc once done. This of course forces a reload of
> the toc and clearing of the flag. What program is this? Seems like
> it should probably eject when it's done.
T
£1.5 Million Has Been Granted To You As A Donation Visit
www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
On 22/05/2018 18:31, Sebastian Andrzej Siewior wrote:
On 2018-05-18 14:31:27 [+0100], John Garry wrote:
On 04/05/2018 15:50, Sebastian Andrzej Siewior wrote:
Since commit 312d3e56119a ("[SCSI] libsas: remove ata_port.lock
management duties from lldds") the sas_ata_qc_issue() function unlocks
th
Hello!
On 5/22/2018 9:15 PM, Kees Cook wrote:
To avoid introducing problems like those fixed in commit f7068114d45e
("sr: pass down correctly sized SCSI sense buffer"), this creates a macro
wrapper for scsi_execute() that verifies the size of the sense buffer
similar to what was done for comman
63 matches
Mail list logo
