On 05/27/14 07:40, Hannes Reinecke wrote:
On 05/26/2014 05:14 PM, Bart Van Assche wrote:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index f17aa7a..5232583 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -193,7 +193,7 @@
(Resending; mailer rejected it ...)
On 05/27/2014 08:08 AM, Bart Van Assche wrote:
On 05/27/14 07:40, Hannes Reinecke wrote:
On 05/26/2014 05:14 PM, Bart Van Assche wrote:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index f17aa7a..5232583 100644
---
On 05/26/14 17:23, Paolo Bonzini wrote:
Il 26/05/2014 17:14, Bart Van Assche ha scritto:
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..c972eab 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -334,7 +334,7 @@ void scsi_put_command(struct scsi_cmnd *cmd)
On Tue, 2014-05-27 at 10:06 +0200, Bart Van Assche wrote:
On 05/26/14 17:23, Paolo Bonzini wrote:
Il 26/05/2014 17:14, Bart Van Assche ha scritto:
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 88d46fe..c972eab 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
On 05/27/14 10:09, James Bottomley wrote:
On Tue, 2014-05-27 at 10:06 +0200, Bart Van Assche wrote:
As you probably know scsi_put_command() can get called from softirq
context. A BUG_ON() in that context might make it unnecessary hard for a
user to collect call traces.
Why? The messages
On Tue, 2014-05-27 at 10:36 +0200, Bart Van Assche wrote:
On 05/27/14 10:09, James Bottomley wrote:
On Tue, 2014-05-27 at 10:06 +0200, Bart Van Assche wrote:
As you probably know scsi_put_command() can get called from softirq
context. A BUG_ON() in that context might make it unnecessary
Il 27/05/2014 10:56, James Bottomley ha scritto:
The whole reason BUG_ON doesn't leave a log trace is to try to prevent
corruption propagating to the data storage devices. What you propose
would be inviting that corruption in the name of getting a log entry.
Even this is not entirely correct.
Il 26/05/2014 17:14, Bart Van Assche ha scritto:
scsi_put_command() is either invoked before a command is queued or
after a command has completed. scsi_cmnd.abort_work is scheduled
after a command has timed out and before it is finished. The block
layer guarantees that either the
On Mon, 2014-05-26 at 17:23 +0200, Paolo Bonzini wrote:
Il 26/05/2014 17:14, Bart Van Assche ha scritto:
scsi_put_command() is either invoked before a command is queued or
after a command has completed. scsi_cmnd.abort_work is scheduled
after a command has timed out and before it is
On 05/26/2014 05:14 PM, Bart Van Assche wrote:
scsi_put_command() is either invoked before a command is queued or
after a command has completed. scsi_cmnd.abort_work is scheduled
after a command has timed out and before it is finished. The block
layer guarantees that either the softirq_done_fn()
10 matches
Mail list logo