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
-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 and/or reentrancy in
scmd_eh_abort_handler
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
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
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_command without
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 run
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.
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
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
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
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
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
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. You can then
13 matches
Mail list logo
