Hi all,
I'm trying to understand asynchronous abort in the current upstream
code, and the code seems to have some dubious locking.
Here are some examples of the issue:
1) dangling pointers: scsi_put_command calls cancel_delayed_work(), but
that doesn't mean that the scmd_eh_abort_handler cou
On 05/19/14 16:08, Paolo Bonzini wrote:
> 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
> concurrently, and call scsi_finish_command without any lock protecting
> the calls. You can then get memory corruption.
I'm not sure what the recommended approach is to address this ra
On Mon, May 19, 2014 at 05:08:56PM +0200, Bart Van Assche wrote:
> On 05/19/14 16:08, Paolo Bonzini wrote:
> > 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
> > concurrently, and call scsi_finish_command without any lock protecting
> > the calls. You can then get memory corr
Il 19/05/2014 17:08, Bart Van Assche ha scritto:
On 05/19/14 16:08, Paolo Bonzini wrote:
2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
concurrently, and call scsi_finish_command without any lock protecting
the calls. You can then get memory corruption.
I'm not sure what
On 05/19/14 18:09, Paolo Bonzini wrote:
> Il 19/05/2014 17:08, Bart Van Assche ha scritto:
>> On 05/19/14 16:08, Paolo Bonzini wrote:
>>> 2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
>>> concurrently, and call scsi_finish_command without any lock protecting
>>> the calls. Y
On 05/19/14 18:43, Bart Van Assche wrote:
> On 05/19/14 18:09, Paolo Bonzini wrote:
>> Il 19/05/2014 17:08, Bart Van Assche ha scritto:
>>> On 05/19/14 16:08, Paolo Bonzini wrote:
2) reentrancy: the softirq handler and scmd_eh_abort_handler can run
concurrently, and call scsi_finish_comma
On 05/20/14 09:32, Bart Van Assche wrote:
> On 05/19/14 18:43, Bart Van Assche wrote:
>> On 05/19/14 18:09, Paolo Bonzini wrote:
>>> Il 19/05/2014 17:08, Bart Van Assche ha scritto:
On 05/19/14 16:08, Paolo Bonzini wrote:
> 2) reentrancy: the softirq handler and scmd_eh_abort_handler can r
On 05/19/14 16:08, Paolo Bonzini wrote:
> 1) dangling pointers: scsi_put_command calls cancel_delayed_work(), but
> that doesn't mean that the scmd_eh_abort_handler couldn't be already
> running. If the scmd_eh_abort_handler starts while the softirq handler
> is calling scsi_put_command (e.g. scsi
Il 20/05/2014 10:10, Bart Van Assche ha scritto:
REQ_ATOM_COMPLETE is already set before scsi_eh_scmd_add() is called
since that function is only invoked after the block layer has marked a
request as "complete". The only callers of scsi_eh_scmd_add() are
scsi_softirq_done(), scsi_times_out() and
Is it possible that when scsi_done is invoked, the scsi command or the
request has been freed and then reallocated for a new I/O request? Because
of this the bit flag REQ_ATOM_COMPLETE becomes unreliable. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the b
Il 21/05/2014 16:16, Mark Wu ha scritto:
Is it possible that when scsi_done is invoked, the scsi command or the
request has been freed and then reallocated for a new I/O request? Because
of this the bit flag REQ_ATOM_COMPLETE becomes unreliable. Thanks!
It is up to the driver to ensure that t
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Paolo Bonzini
> Sent: Wednesday, 21 May, 2014 3:34 PM
> To: Mark Wu; linux-scsi@vger.kernel.org
> Subject: Re: dangling pointers an
Il 23/05/2014 03:28, Elliott, Robert (Server Storage) ha scritto:
Depending on the transport, there may be a race condition between
the command status and the ABORT TASK response; the ABORT TASK
response might get back first. I think that means
scsi_eh_abort_handler's call to scsi_finish_command
13 matches
Mail list logo
