All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-kernel@vger.kernel.org, jaxboe@fusionio.com,
	sergey.senozhatsky@gmail.com, tj@kernel.org, jmoyer@redhat.com,
	snitzer@redhat.com
Subject: Re: [PATCH 0/3] [RFC] block: Enforce that ->queue_lock is initialized during call to blk_cleanup_queue()
Date: Tue, 22 Feb 2011 15:20:03 +1100	[thread overview]
Message-ID: <20110222152003.09698a39@notabene.brown> (raw)
In-Reply-To: <1298346817-26144-1-git-send-email-vgoyal@redhat.com>

On Mon, 21 Feb 2011 22:53:34 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:

> Hi All,
> 
> Currently it is not clear what's the status of ->queue_lock when
> blk_cleanup_queue() is called. Now block throttle code (blk_throtl_exit())
> requires queue lock to be initialized as it takes the spin lock, so we need
> some kind of clear convention that when is it safe to assume that queue lock
> is initiliazed and blk_throtle_exit() can be called safely.
> 
> We recently ran into issues with loop driver which was trying to free
> up queue almost immediately after block_alloc_queue() due to some internal
> errors. Also NeilBrown complained that in current form, md provides its
> own spinlock and zaps that before blk_cleanup_queue() call and that will
> have issues with throttling code. Neil has not fixed the issue with
> md driver and queued up a patch in this tree.
> 
> So there is a need to make sure blk_throtl_exit() can be called safely
> and to also catch any errors if some drivers are not doing so. This
                                                   ^^^
"now" !!  I make that typo all the time too :-(

> patch series puts a WARN_ON(!q->queue_lock) in blk_cleanup_queue() and
> moves the queue lock initialization in queue allocation code. Also it
> move blk_throtl_exit() from release_queue() to cleanup_queue().

I'm not sure there is a lot of point in the WARN_ON.
Modules that replace ->queue_lock are unlikely to set it to NULL when
done, they will just free the structure that it points into.
This will already be caught if you compile with DEBUG_PAGEALLOC and
DEBUG_SPINLOCK (I think) and there is not much else you can do to catch
these.

Thanks,
NeilBrown


> 
> These pathes are only boot tested on one machine. Before I do more
> extensive testing, I wanted to throw it out there and figure out
> if it makes sense or not.
> 
> Thanks
> Vivek
> 
> Vivek Goyal (3):
>   block: Initialize ->queue_lock to internal lock at queue allocation
>     time
>   loop: No need to initialize ->queue_lock explicitly before calling
>     blk_cleanup_queue()
>   block: Move blk_throtl_exit() call to blk_cleanup_queue()
> 
>  block/blk-core.c       |   26 ++++++++++++++++++++++++--
>  block/blk-settings.c   |    7 -------
>  block/blk-sysfs.c      |    2 --
>  block/blk-throttle.c   |    2 +-
>  drivers/block/loop.c   |    3 ---
>  include/linux/blkdev.h |    2 --
>  6 files changed, 25 insertions(+), 17 deletions(-)


  parent reply	other threads:[~2011-02-22  4:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-22  3:53 [PATCH 0/3] [RFC] block: Enforce that ->queue_lock is initialized during call to blk_cleanup_queue() Vivek Goyal
2011-02-22  3:53 ` [PATCH 1/3] block: Initialize ->queue_lock to internal lock at queue allocation time Vivek Goyal
2011-02-22  3:53 ` [PATCH 2/3] loop: No need to initialize ->queue_lock explicitly before calling blk_cleanup_queue() Vivek Goyal
2011-02-22  7:30   ` Sergey Senozhatsky
2011-02-22 14:20     ` Vivek Goyal
2011-02-22 14:48       ` Sergey Senozhatsky
2011-02-22  3:53 ` [PATCH 3/3] block: Move blk_throtl_exit() call to blk_cleanup_queue() Vivek Goyal
2011-02-22  4:20 ` NeilBrown [this message]
2011-02-22 14:17   ` [PATCH 0/3] [RFC] block: Enforce that ->queue_lock is initialized during " Vivek Goyal

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=20110222152003.09698a39@notabene.brown \
    --to=neilb@suse.de \
    --cc=jaxboe@fusionio.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=snitzer@redhat.com \
    --cc=tj@kernel.org \
    --cc=vgoyal@redhat.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.