From: Mike Snitzer <snitzer@redhat.com>
To: Bart Van Assche <Bart.VanAssche@wdc.com>, hch@lst.de
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [for-4.16 PATCH 1/2] block: cope with gendisk's 'queue' being added later
Date: Tue, 9 Jan 2018 19:33:03 -0500 [thread overview]
Message-ID: <20180110003302.GA19063@redhat.com> (raw)
In-Reply-To: <20180109234133.GA18842@redhat.com>
On Tue, Jan 09 2018 at 6:41pm -0500,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Tue, Jan 09 2018 at 6:04pm -0500,
> Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
>
> > On Tue, 2018-01-09 at 17:10 -0500, Mike Snitzer wrote:
> > > diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> > > index 870484eaed1f..0b0dda8e2420 100644
> > > --- a/block/blk-sysfs.c
> > > +++ b/block/blk-sysfs.c
> > > @@ -919,8 +919,20 @@ int blk_register_queue(struct gendisk *disk)
> > > ret = 0;
> > > unlock:
> > > mutex_unlock(&q->sysfs_lock);
> > > +
> > > + /*
> > > + * Take an extra ref on queue which will be put on disk_release()
> > > + * so that it sticks around as long as @disk is there.
> > > + */
> > > + WARN_ON_ONCE(!blk_get_queue(q));
> > > +
> > > + WARN_ON(sysfs_create_link(&dev->kobj,
> > > + &q->backing_dev_info->dev->kobj,
> > > + "bdi"));
> > > +
> > > return ret;
> > > }
> > > +EXPORT_SYMBOL_GPL(blk_register_queue);
> >
> > Hello Mike,
> >
> > So the sysfs_create_link() call is moved from register_disk() into
> > blk_register_queue() but the sysfs_remove_link() call stays in del_gendisk()?
> > Are you sure that you want this asymmetry?
>
> My focus was on the add_disk() side of things, due to disk->queue
> possibly being NULL on add. But on remove all was basically left
> unmodified (aside from removing the WARN_ON).
>
> I dont think the asymmetry is a big deal but I can fix it. I'll wait
> for more feedback before sending out a v2 though.
But while reviewing this asymetry I found that the sysfs_create_link()
that I moved to blk_register_queue() needs to be guarded against
GENHD_FL_HIDDEN -- I didn't notice the GENHD_FL_HIDDEN early return in
register_disk(). I'll get that fixed up.
But unrelated to my patch: I think I found another curious imbalance, in
current upstream code, relative to GENHD_FL_HIDDEN.
bdi_register_owner() is only called if !GENHD_FL_HIDDEN but
bdi_unregister() is called unconditionally. Not sure what is needed to
address that issue because I'd have thought that the bdi would be needed
regardless of GENHD_FL_HIDDEN. Christoph?
next prev parent reply other threads:[~2018-01-10 0:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 22:10 [for-4.16 PATCH 0/2] block: cope with gendisk's 'queue' being added later Mike Snitzer
2018-01-09 22:10 ` [for-4.16 PATCH 1/2] " Mike Snitzer
2018-01-09 23:04 ` Bart Van Assche
2018-01-09 23:04 ` Bart Van Assche
2018-01-09 23:41 ` Mike Snitzer
2018-01-10 0:33 ` Mike Snitzer [this message]
2018-01-09 22:10 ` [for-4.16 PATCH 2/2] dm: fix awkward request_queue initialization Mike Snitzer
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=20180110003302.GA19063@redhat.com \
--to=snitzer@redhat.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
/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.