From: Jens Axboe <jens.axboe@oracle.com>
To: Mike Anderson <andmike@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org,
James Bottomley <James.Bottomley@suse.de>,
dm-devel@redhat.com
Subject: Re: [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
Date: Wed, 5 May 2010 10:21:50 +0200 [thread overview]
Message-ID: <20100505082150.GY27497@kernel.dk> (raw)
In-Reply-To: <20100504175855.GB16156@linux.vnet.ibm.com>
On Tue, May 04 2010, Mike Anderson wrote:
> Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Mon, May 03 2010, Mike Anderson wrote:
> > > Having REQ_DONTPREP set on a request can indicated that resources have been
> > > allocated for this request. In elv_abort_queue skip requests with
> > > REQ_DONTPREP set to avoid leaking resources.
> >
> > This also seems weird, are you coding the API backwards from what SCSI
> > currently has implemented?
> >
>
> Yes I was coding to current SCSI implementation.
>
> > Would seem a lot cleaner to separate dont-prep from already-prepped.
> >
>
> I assumed to do this we would need another request flag indicating
> ??REQ_PREPPED?? that would need to be set in the prep function. Then
> this flag would be checked vs REQ_DONTPREP to call the unprep_fn or did you
> mean something else?
Yeah, something like that, cleanly seperating the state of needing
unprep vs never being prepped. As that's a driver state, most drivers
should be able to get that info without needing an extra flag. But it's
probably cleaner to add the REQ_PREPPED flag and only call back into the
driver if the rq really needs an unprep.
--
Jens Axboe
next prev parent reply other threads:[~2010-05-05 8:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 3:36 [PATCH 0/9] blk: scsi: blk abort queue updates Mike Anderson
2010-05-04 3:37 ` [PATCH 1/9] blk: Do not abort requests if queue is stopped Mike Anderson
2010-05-04 10:40 ` Hannes Reinecke
2010-05-04 10:45 ` Jens Axboe
2010-05-05 4:52 ` Mike Anderson
2010-05-05 18:13 ` Mike Christie
2010-05-05 18:18 ` Mike Anderson
2010-05-04 3:37 ` [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set Mike Anderson
2010-05-04 10:40 ` Hannes Reinecke
2010-05-04 10:47 ` Jens Axboe
2010-05-04 17:58 ` Mike Anderson
2010-05-05 8:21 ` Jens Axboe [this message]
2010-05-04 3:37 ` [PATCH 3/9] blk: Add a unprep_rq_fn Mike Anderson
2010-05-04 10:41 ` Hannes Reinecke
2010-05-04 3:37 ` [PATCH 4/9] blk: Call unprep_fn from elv_abort_queue is available Mike Anderson
2010-05-04 10:42 ` Hannes Reinecke
2010-05-04 10:42 ` [dm-devel] " Hannes Reinecke
2010-05-04 3:37 ` [PATCH 5/9] scsi: Add a scsi_unprep_fn Mike Anderson
2010-05-04 10:43 ` [dm-devel] " Hannes Reinecke
2010-05-04 10:48 ` Jens Axboe
2010-05-04 3:37 ` [PATCH 6/9] blk: Add request atomic flag for abort Mike Anderson
2010-05-04 10:43 ` [dm-devel] " Hannes Reinecke
2010-05-04 3:37 ` [PATCH 7/9] blk: Mark requests aborted Mike Anderson
2010-05-04 10:44 ` Hannes Reinecke
2010-05-04 3:37 ` [PATCH 8/9] scsi: Add scsi_requeue_request function Mike Anderson
2010-05-04 3:37 ` [PATCH 9/9] scsi: Add blk_request_aborted check Mike Anderson
2010-05-04 10:45 ` Hannes Reinecke
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=20100505082150.GY27497@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=James.Bottomley@suse.de \
--cc=andmike@linux.vnet.ibm.com \
--cc=dm-devel@redhat.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.