All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Dalecki <dalecki@evision.ag>
To: Jens Axboe <axboe@suse.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	martin@dalecki.de, linux-kernel@vger.kernel.org
Subject: Re: please DON'T run 2.5.27 with IDE!
Date: Wed, 24 Jul 2002 15:08:57 +0200	[thread overview]
Message-ID: <3D3EA6E9.7000601@evision.ag> (raw)
In-Reply-To: 20020724125037.GB15201@suse.de

Jens Axboe wrote:

>>>>2.5.27:drivers/block/ll_rw_blk.c
>>>>void blk_start_queue(request_queue_t *q)
>>>>{
>>>>        if (test_and_clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
>>>>                unsigned long flags;
>>>>
>>>>                spin_lock_irqsave(q->queue_lock, flags);
>>>>                if (!elv_queue_empty(q))
>>>>                        q->request_fn(q);
>>>>                spin_unlock_irqrestore(q->queue_lock, flags);
>>>>        }
>>>>}

> There were buggy versions at one point, however they may not have made it
> into a full release. In that case it was just bk version of 2.5.19-pre
> effectively. I forget the details :-)

Naj - it's far more trivial I just looked at wrong tree at hand...
But anyway. What happens if somone does set QUEUE_FLAG_STOPPED
between the test_and_claer_bit and taking the spin_lock? Setting
the QUEUE_FLAG_STOPPED isn't maintaining the spin_lock protection!

My goal is to make sure that the QUEUE_FLAG_STOPPED has a valid value
*inside* the q->request_fn call.

This here is where it's supposed to be set:

void blk_stop_queue(request_queue_t *q)
{
         unsigned long flags;

         spin_lock_irqsave(q->queue_lock, flags);
         blk_remove_plug(q);
         spin_unlock_irqrestore(q->queue_lock, flags);

         set_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
}

And I don't see anything preventing the above problem.

It sould perhaps be?

void blk_stop_queue(request_queue_t *q)
{
         unsigned long flags;

         spin_lock_irqsave(q->queue_lock, flags);
         blk_remove_plug(q);
         set_bit(QUEUE_FLAG_STOPPED, &q->queue_flags); /* Notice 
spinlock still held! */
         spin_unlock_irqrestore(q->queue_lock, flags);
}

void blk_start_queue(request_queue_t *q)
{
         if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
                 unsigned long flags;

                 spin_lock_irqsave(q->queue_lock, flags);
		if (!test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
			spin_unlock_irqsave(q->queue_lock, flags);
			return;
		}
                 clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
                 if (!elv_queue_empty(q))
                         q->request_fn(q);
                 spin_unlock_irqrestore(q->queue_lock, flags);
         }
}

At least I couldn't see any harm in doing it like above.
And again. I think it would assert that the flag is well defined inside
q->request_fn().


  reply	other threads:[~2002-07-24 13:11 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-22 19:37 please DON'T run 2.5.27 with IDE! Bartlomiej Zolnierkiewicz
2002-07-22 20:39 ` Andries Brouwer
2002-07-22 23:25   ` Thunder from the hill
2002-07-23  0:39 ` A Guy Called Tyketto
2002-07-23  0:58   ` Thunder from the hill
2002-07-23  1:10     ` Bartlomiej Zolnierkiewicz
2002-07-23  8:03 ` Morten Helgesen
2002-07-23 12:47   ` Bartlomiej Zolnierkiewicz
2002-07-23 13:00     ` Marcin Dalecki
2002-07-23 13:42       ` Bartlomiej Zolnierkiewicz
2002-07-23 13:58         ` Marcin Dalecki
2002-07-23 19:52           ` Jan Harkes
2002-07-23 20:08             ` Andre Hedrick
2002-07-24 10:24             ` Marcin Dalecki
2002-07-23 20:24           ` Bartlomiej Zolnierkiewicz
2002-07-24 10:30             ` Marcin Dalecki
2002-07-24 10:54               ` Bartlomiej Zolnierkiewicz
2002-07-24 11:35                 ` Marcin Dalecki
2002-07-24 11:53                   ` Jens Axboe
2002-07-24 12:08                     ` Marcin Dalecki
2002-07-24 12:39                   ` Bartlomiej Zolnierkiewicz
2002-07-24 12:41                     ` Jens Axboe
2002-07-24 12:49                       ` Bartlomiej Zolnierkiewicz
2002-07-24 12:50                         ` Jens Axboe
2002-07-24 13:08                           ` Marcin Dalecki [this message]
2002-07-24 13:25                             ` Jens Axboe
2002-07-24 13:35                               ` Bartlomiej Zolnierkiewicz
2002-07-24 13:36                                 ` Jens Axboe
2002-07-24 13:38                                   ` Marcin Dalecki
2002-07-24 13:35                               ` Marcin Dalecki
2002-07-24 12:43                   ` Bartlomiej Zolnierkiewicz
2002-07-24 13:10                     ` Marcin Dalecki
2002-07-24 13:21                       ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2002-07-22 19:43 Petr Vandrovec
2002-07-22 19:46 ` Bartlomiej Zolnierkiewicz

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=3D3EA6E9.7000601@evision.ag \
    --to=dalecki@evision.ag \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin@dalecki.de \
    /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.