From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: axboe@kernel.dk, Ming Lei <tom.leiming@gmail.com>,
hch@lst.de, Bart.VanAssche@wdc.com, dm-devel@redhat.com,
linux-block@vger.kernel.org
Subject: Re: [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred
Date: Thu, 11 Jan 2018 12:04:31 -0500 [thread overview]
Message-ID: <20180111170430.GA30621@redhat.com> (raw)
In-Reply-To: <804df5df-2598-df69-757d-85df18185d4c@suse.de>
On Thu, Jan 11 2018 at 2:46am -0500,
Hannes Reinecke <hare@suse.de> wrote:
> On 01/11/2018 03:12 AM, Mike Snitzer wrote:
> >
> > diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> > index 870484eaed1f..2395122875b4 100644
> > --- a/block/blk-sysfs.c
> > +++ b/block/blk-sysfs.c
> > @@ -929,6 +930,9 @@ void blk_unregister_queue(struct gendisk *disk)
> > if (WARN_ON(!q))
> > return;
> >
> > + if (!test_bit(QUEUE_FLAG_REGISTERED, &disk->queue->queue_flags))
> > + return;
> > +
> > mutex_lock(&q->sysfs_lock);
> > queue_flag_clear_unlocked(QUEUE_FLAG_REGISTERED, q);
> > mutex_unlock(&q->sysfs_lock);
> Why can't we use test_and_clear_bit() here?
> Shouldn't that relieve the need for the mutex_lock() here, too?
FYI, I looked at this and then got concerned with it enough to chat with
Mikulas (cc'd) about it, here is what he said:
11:54 <mikulas> if (!test_and_clear_bit(QUEUE_FLAG_REGISTERED, &q->queue_flags))
11:55 <mikulas> this is buggy - the operation test_and_clear_bit is atomic - but if it races with some non-atomic read-modify-write operation on q->queue_flags, then the atomic modification would be lost
11:56 <mikulas> you must use always atomic accesses on q->queue_flags or always non-atomic accesses inside a mutex
11:56 <mikulas> queue_flag_clear_unlocked uses non-atomic __clear_bit
11:57 <mikulas> other functions in include/linux/blkdev.h also use non-atomic operations - so you cannot mix them with atomic operations
So my v4, that I'll send out shortly, won't be using test_and_clear_bit()
Thanks,
Mike
next prev parent reply other threads:[~2018-01-11 17:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 2:12 [for-4.16 PATCH v3 0/3] block/dm: allow DM to defer blk_register_queue() until ready Mike Snitzer
2018-01-11 2:12 ` [for-4.16 PATCH v3 1/3] block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN Mike Snitzer
2018-01-11 2:48 ` Ming Lei
2018-01-11 7:40 ` Hannes Reinecke
2018-01-11 2:12 ` [for-4.16 PATCH v3 2/3] block: allow gendisk's request_queue registration to be deferred Mike Snitzer
2018-01-11 2:54 ` Ming Lei
2018-01-11 7:46 ` Hannes Reinecke
2018-01-11 17:04 ` Mike Snitzer [this message]
2018-01-11 17:18 ` Bart Van Assche
2018-01-11 17:18 ` Bart Van Assche
2018-01-11 17:29 ` Mike Snitzer
2018-01-11 17:47 ` Bart Van Assche
2018-01-11 17:47 ` Bart Van Assche
2018-01-11 19:20 ` Mike Snitzer
2018-01-11 19:32 ` Bart Van Assche
2018-01-11 19:32 ` Bart Van Assche
2018-01-11 19:50 ` Mike Snitzer
2018-01-11 7:56 ` Hannes Reinecke
2018-01-11 16:03 ` Mike Snitzer
2018-01-11 2:12 ` [for-4.16 PATCH v3 3/3] dm: fix awkward and incomplete request_queue initialization Mike Snitzer
2018-01-11 2:56 ` Ming Lei
2018-01-11 7:57 ` Hannes Reinecke
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=20180111170430.GA30621@redhat.com \
--to=snitzer@redhat.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=tom.leiming@gmail.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.