Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread Bart Van Assche
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 @@

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread Hannes Reinecke
(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 ---

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread Bart Van Assche
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)

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread James Bottomley
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

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread Bart Van Assche
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

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread James Bottomley
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

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-27 Thread Paolo Bonzini
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.

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-26 Thread Paolo Bonzini
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

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-26 Thread James Bottomley
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

Re: [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler

2014-05-26 Thread Hannes Reinecke
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()