From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Marcin Dalecki <dalecki@evision.ag>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.28 small REQ_SPECIAL abstraction
Date: Mon, 29 Jul 2002 07:37:46 +0200 [thread overview]
Message-ID: <20020729073746.A4437@suse.de> (raw)
In-Reply-To: <200207282013.g6SKDjg02769@localhost.localdomain>
On Sun, Jul 28 2002, James Bottomley wrote:
> > You are right the
> > > rq->flags &= REQ_QUEUED;
> > > and the
> > > if (blk_rq_tagged(rq))
> > blk_queue_end_tag(q, rq);
> > > should be just removed and things are fine.
> > They only survive becouse they don't provide a tag for the request in
> > first place.
> > > Thanks for pointing it out.
>
>
> Please don't remove this.
>
> insert_special isn't just used to start new requests, it's also used to queue
> incoming requests that cannot be processed by the device (host adapter,
> queue_full etc.).
>
> In this latter case, the tag is already begun, so it needs to go back with
> end_tag (we start a new tag when the device begins processing again).
>
> I own up to introducing the &= REQ_QUEUED rubbish---I was just keeping the
> original placement of the flag clearing code, but now we need to preserve
> whether the request was queued or not for the blk_rq_tagged check. On
> reflection it would have been better just to set the flags to REQ_SPECIAL |
> REQ_BARRIER after the end tag code.
I think you are missing the point. The stuff should not be in the
_generic_ blk_insert_request(). As I posted in my first reply to Martin,
SCSI needs to clear the tag before calling blk_insert_request() if it
needs to.
> axboe@suse.de said:
> > But the crap still got merged, sigh... Yet again an excellent point of
> > why stuff like this should go through the maintainer. Apparently Linus
> > blindly applies this stuff.
>
> Hmm, well I sent it to you and you are the Maintainer.
I've never seen it?!
--
Jens Axboe
next prev parent reply other threads:[~2002-07-29 5:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-28 20:13 [PATCH] 2.5.28 small REQ_SPECIAL abstraction James Bottomley
2002-07-29 5:37 ` Jens Axboe [this message]
2002-07-29 5:55 ` Jens Axboe
2002-07-29 6:23 ` Linus Torvalds
2002-07-29 6:34 ` Jens Axboe
2002-07-29 6:58 ` Linus Torvalds
2002-07-29 10:43 ` Jens Axboe
2002-07-29 13:44 ` James Bottomley
2002-07-29 13:50 ` Marcin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2002-07-28 23:59 Andries.Brouwer
2002-07-29 0:33 ` Linus Torvalds
2002-07-29 0:52 ` Dave Jones
2002-07-30 0:50 ` Rob Landley
2002-07-24 21:13 Linux-2.5.28 Linus Torvalds
2002-07-26 6:03 ` [PATCH] 2.5.28 small REQ_SPECIAL abstraction Marcin Dalecki
2002-07-26 14:38 ` Jens Axboe
2002-07-26 15:09 ` Marcin Dalecki
2002-07-28 19:25 ` Jens Axboe
2002-07-28 23:32 ` Linus Torvalds
2002-07-29 5:39 ` Jens Axboe
2002-07-29 5:50 ` Linus Torvalds
2002-07-29 10:24 ` Marcin Dalecki
2002-07-29 10:44 ` Jens Axboe
2002-07-29 11:05 ` Marcin Dalecki
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=20020729073746.A4437@suse.de \
--to=axboe@suse.de \
--cc=James.Bottomley@steeleye.com \
--cc=dalecki@evision.ag \
--cc=linux-kernel@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.