All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
	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 12:43:51 +0200	[thread overview]
Message-ID: <20020729124351.C4861@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0207282352030.10092-100000@home.transmeta.com>

On Sun, Jul 28 2002, Linus Torvalds wrote:
> 
> 
> On Mon, 29 Jul 2002, Jens Axboe wrote:
> >
> > I think Martin's was wrong in concept, mine was wrong in implementation.
> 
> I don't understand why you think the concept is wrong. Right now all users
> clearly do want to free the tag on re-issue, and doing so clearly cleans
> up the code and avoids duplication.
> 
> So I still don't see the advantage of your patch, even once you've fixed
> the locking issue.

Ok... I had two issues with the patch. 1) it did

	rq->flags &= REQ_QUEUED;

which is just broken. 2) it combined the act of inserting back into the
block queue with clearing the tag associated with the request. #1 is
clearly a bug that should be fixed regardless of what we do. Right now,
yes, the only user of blk_insert_request (SCSI) needs the tag cleared. I
still don't think that's a reason to mingle the two different tasks into
one. Code duplication is not an argument, the two scsi_insert_* should
be folded into one. The only difference is SRpnt->sr_request vs
SCpnt->request after all.

> HOWEVER, if you really think that some future users might not want to have
> the tag played with, how about making the "at_head" thing a flags field,
> and letting people say so by having "INSERT_NOTAG" (and making the
> existing bit be INSERT_ATHEAD).
> 
> So then the SCSI users would look like
> 
> 	blk_insert_request(q, SRpnt->sr_request,
> 		at_head ? INSERT_ATHEAD : 0,
> 		SRpnt)
> 
> while your future non-tag user might do
> 
> 	blk_insert_request(q, newreq,
> 		INSERT_ATHEAD | INSERT_NOTAG,
> 		channel);
> 
> _without_ having that unnecessary code duplication.

*shrug* I guess we could do that. I don't see any immediate use beyond
at_head/back and tag clearing.

I'll back down, it's not a matter of life and death after all. Here's
the minimal patch that corrects the flag thing, and also makes
blk_insert_request() conform to kernel style. Are we all happy?

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.509   -> 1.510  
#	drivers/block/ll_rw_blk.c	1.96    -> 1.97   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/07/29	axboe@burns.home.kernel.dk	1.510
# fix REQ_QUEUED clearing in blk_insert_request()
# --------------------------------------------
#
diff -Nru a/drivers/block/ll_rw_blk.c b/drivers/block/ll_rw_blk.c
--- a/drivers/block/ll_rw_blk.c	Mon Jul 29 12:42:43 2002
+++ b/drivers/block/ll_rw_blk.c	Mon Jul 29 12:42:43 2002
@@ -1253,7 +1253,7 @@
  *    host that is unable to accept a particular command.
  */
 void blk_insert_request(request_queue_t *q, struct request *rq,
-		int at_head, void *data)
+			int at_head, void *data)
 {
 	unsigned long flags;
 
@@ -1262,15 +1262,18 @@
 	 * must not attempt merges on this) and that it acts as a soft
 	 * barrier
 	 */
-	rq->flags &= REQ_QUEUED;
 	rq->flags |= REQ_SPECIAL | REQ_BARRIER;
 
 	rq->special = data;
 
 	spin_lock_irqsave(q->queue_lock, flags);
-	/* If command is tagged, release the tag */
-	if(blk_rq_tagged(rq))
+
+	/*
+	 * If command is tagged, release the tag
+	 */
+	if (blk_rq_tagged(rq))
 		blk_queue_end_tag(q, rq);
+
 	_elv_add_request(q, rq, !at_head, 0);
 	q->request_fn(q);
 	spin_unlock_irqrestore(q->queue_lock, flags);


-- 
Jens Axboe


  reply	other threads:[~2002-07-29 10:40 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
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 [this message]
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=20020729124351.C4861@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@steeleye.com \
    --cc=dalecki@evision.ag \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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.