All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Jens Axboe <jaxboe@fusionio.com>, linux-kernel@vger.kernel.org
Subject: blk_throtl_exit  taking q->queue_lock is problematic
Date: Wed, 16 Feb 2011 18:31:14 +1100	[thread overview]
Message-ID: <20110216183114.26a3613b@notabene.brown> (raw)



Hi,

 I recently discovered that blk_throtl_exit takes ->queue_lock when a blockdev
is finally released.

This is a problem for because by that time the queue_lock doesn't exist any
more.  It is in a separate data structure controlled by the RAID personality
and by the time that the block device is being destroyed the raid personality
has shutdown and the data structure containing the lock has been freed.

This has not been a problem before.  Nothing else takes queue_lock after
blk_cleanup_queue.

I could of course set queue_lock to point to __queue_lock and initialise that,
but it seems untidy and probably violates some locking requirements.

Is there some way you could use some other lock - maybe a global lock, or
maybe used __queue_lock directly ???

Thanks,
NeilBrown

             reply	other threads:[~2011-02-16  7:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-16  7:31 NeilBrown [this message]
2011-02-16 15:53 ` blk_throtl_exit taking q->queue_lock is problematic Vivek Goyal
2011-02-17  0:35   ` NeilBrown
2011-02-17  1:10     ` Vivek Goyal
2011-02-17  5:55       ` NeilBrown
2011-02-17 15:01         ` Vivek Goyal
2011-02-17 16:59         ` Vivek Goyal
2011-02-18  2:40           ` NeilBrown
2011-02-18  3:19             ` Mike Snitzer
2011-02-18  3:33               ` NeilBrown
2011-02-18 14:04                 ` Mike Snitzer
2011-02-18 15:04                 ` Vivek Goyal
2011-02-21  7:24                   ` NeilBrown
2011-02-21 14:42                     ` Vivek Goyal
2011-02-18 15:05             ` Vivek Goyal
2011-02-17 20:00 ` Vivek Goyal
2011-02-18  1:57   ` NeilBrown

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=20110216183114.26a3613b@notabene.brown \
    --to=neilb@suse.de \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.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.