All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Patterson <andrew.patterson@hp.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	"Moore, Eric" <Eric.Moore@lsi.com>
Subject: Re: Deadlock during DV when queue is full
Date: Wed, 30 May 2007 22:19:11 -0600	[thread overview]
Message-ID: <1180585151.6681.2.camel@grinch> (raw)
In-Reply-To: <1180552972.3697.52.camel@mulgrave.il.steeleye.com>

On Wed, 2007-05-30 at 14:22 -0500, James Bottomley wrote:
> On Wed, 2007-05-30 at 21:11 +0200, Jens Axboe wrote:
> > > > > > > > There's no other solution than maintaining a cached request + command
> > > > > > > > for this. libata has a similar issue wrt error handling with ncq, we may
> > > > > > > > need a command in error handling to retrieve the log page.
> > > > > > > 
> > > > > > > Actually, there is another solution: DV is careful only to be using a
> > > > > > > single command for its processes ... if we could use the eh command for
> > > > > > > this, then I think the problem would go away ... unfortunately, that's a
> > > > > > > bit more complex to achieve than it sounds.
> > > > 
> > > > (btw this is not another solution, it's indeed the solution of keeping a
> > > > reserved request :-)
> > > > 
> > > > > > That would be fine, the key is just to have such a reserved command. Is
> > > > > > there also a reserved request?
> > > > > 
> > > > > Yes ... we clean out the failing command in error recovery and reuse it,
> > > > > so we know it has both a command and a request.
> > > > 
> > > > Sounds a bit hackish, unless the failed command never needs to be
> > > > retried.
> > > 
> > > Oh, it does.  We clean it out, save the necessary on the stack and reuse
> > > it, then restore the data and send it for a retry.  Up until a while ago
> > > it was what all the old_ fields were for in the SCSI command; now, after
> > > Christoph fixed it, we save them on the stack instead.
> > 
> > I guess the scsi command doesn't need a whole lot of saved state, but
> > the request does.
> 
> Well, we're careful never to let the block layer see it again.  We have
> a special injection point scsi_send_eh_cmnd() for this.  On the other
> hand ... supposing we were to push it back on the block queue for a
> resend, what would we need to save?  It's fully prepared and set up as
> special because of the attached command, so I'm not sure there would be
> anything, as long as we don't let it go into the normal block completion
> paths ... I'm just wondering if we can get rid of the special injection
> path.
> 
> James
> 
> 

Rather than reusing a request, can we just somehow signal the block
layer to let this command exceed the current nr_request limit and go on
through?  This would be similar to the ioc_batching mechanism currently
in use.

Andrew



  reply	other threads:[~2007-05-31  4:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-28 23:42 Deadlock during DV when queue is full Andrew Patterson
2007-05-30 18:01 ` Jens Axboe
2007-05-30 18:43   ` James Bottomley
2007-05-30 18:55     ` Jens Axboe
2007-05-30 19:02       ` James Bottomley
2007-05-30 19:03         ` Jens Axboe
2007-05-30 19:07           ` James Bottomley
2007-05-30 19:11             ` Jens Axboe
2007-05-30 19:22               ` James Bottomley
2007-05-31  4:19                 ` Andrew Patterson [this message]
2007-05-31  5:31                   ` Jens Axboe

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=1180585151.6681.2.camel@grinch \
    --to=andrew.patterson@hp.com \
    --cc=Eric.Moore@lsi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    /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.