All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Hannes Reinecke <hare@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Ulrich Obergfell <uobergfe@redhat.com>
Subject: Re: dangling pointers and/or reentrancy in scmd_eh_abort_handler?
Date: Tue, 20 May 2014 10:46:51 +0200	[thread overview]
Message-ID: <537B167B.801@acm.org> (raw)
In-Reply-To: <537A105B.4080504@redhat.com>

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_finish_command ->
> scsi_io_completion -> scsi_end_request -> scsi_next_command), the
> pointer to the Scsi_Cmnd* becomes invalid in the middle of the abort
> handler.

Hannes, can you clarify why a cancel_delayed_work() statement was added
in scsi_put_command() ? How can scsi_put_command() get invoked after the
SCSI timeout handler queued &scmd->abort_work and before the function
associated with that work struct (scmd_eh_abort_handler()) is called ?

Thanks,

Bart.

      parent reply	other threads:[~2014-05-20  8:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-19 14:08 dangling pointers and/or reentrancy in scmd_eh_abort_handler? Paolo Bonzini
2014-05-19 15:08 ` Bart Van Assche
2014-05-19 15:25   ` Christoph Hellwig
2014-05-19 16:09   ` Paolo Bonzini
2014-05-19 16:43     ` Bart Van Assche
2014-05-20  7:32       ` Bart Van Assche
2014-05-20  8:10         ` Bart Van Assche
2014-05-20  8:40           ` Paolo Bonzini
2014-05-21 14:16       ` Mark Wu
2014-05-21 20:34         ` Paolo Bonzini
2014-05-23  1:28           ` Elliott, Robert (Server Storage)
2014-05-23  9:22             ` Paolo Bonzini
2014-05-20  8:46 ` Bart Van Assche [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537B167B.801@acm.org \
    --to=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=uobergfe@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.