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.
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 unneces
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 mes
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/s
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_cm
(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
--- a/drivers/scsi/scsi_e
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 @@ scsi_abort_c
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()
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 f
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 softirq_done_fn(
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() or the
rq_timed_out_fn() function is invoked but
11 matches
Mail list logo
