All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"hare@suse.de" <hare@suse.de>,
	"tom.leiming@gmail.com" <tom.leiming@gmail.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred
Date: Thu, 11 Jan 2018 21:03:20 -0500	[thread overview]
Message-ID: <20180112020319.GC32298@redhat.com> (raw)
In-Reply-To: <1515717455.2752.82.camel@wdc.com>

On Thu, Jan 11 2018 at  7:37pm -0500,
Bart Van Assche <Bart.VanAssche@wdc.com> wrote:

> On Thu, 2018-01-11 at 15:14 -0500, Mike Snitzer wrote:
> > -void device_add_disk(struct device *parent, struct gendisk *disk)
> > +void device_add_disk_no_queue_reg(struct device *parent, struct gendisk *disk)
> >  {
> >  	dev_t devt;
> >  	int retval;
> > @@ -682,7 +682,6 @@ void device_add_disk(struct device *parent, struct gendisk *disk)
> >  				    exact_match, exact_lock, disk);
> >  	}
> >  	register_disk(parent, disk);
> > -	blk_register_queue(disk);
> >  
> >  	/*
> >  	 * Take an extra ref on queue which will be put on disk_release()
> > @@ -693,6 +692,21 @@ void device_add_disk(struct device *parent, struct gendisk *disk)
> >  	disk_add_events(disk);
> >  	blk_integrity_add(disk);
> >  }
> > +EXPORT_SYMBOL(device_add_disk_no_queue_reg);
> 
> Hello Mike,
> 
> This change can increase the time between the generation of the disk uevent
> and the registration of the request queue sysfs attributes. Can this cause
> any udev rules to fail?

Certainly not for DM (DM has very sophisticated udev rules that wait for
the final dm generated "CHANGE" event before considering a device to be
"ready").

But are you asking about non-DM devices?  I cannot see, what amounts to,
moving blk_register_queue() to the end of device_add_disk() as reason for
concern.  If it were there technically would already be that race.

Mike

  reply	other threads:[~2018-01-12  2:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11 20:14 [for-4.16 PATCH v4 0/4] block/dm: allow DM to defer blk_register_queue() until ready Mike Snitzer
2018-01-11 20:14 ` [for-4.16 PATCH v4 1/4] block: only bdi_unregister() in del_gendisk() if !GENHD_FL_HIDDEN Mike Snitzer
2018-01-11 20:14 ` [for-4.16 PATCH v4 2/4] block: use queue_lock when clearing QUEUE_FLAG_REGISTERED in blk_unregister_queue Mike Snitzer
2018-01-12  0:28   ` Bart Van Assche
2018-01-12  0:28     ` Bart Van Assche
2018-01-12  2:53     ` Mike Snitzer
2018-01-12  7:09   ` Ming Lei
2018-01-12 12:53     ` Mike Snitzer
2018-01-12 14:14       ` Ming Lei
2018-01-12 15:05         ` Mike Snitzer
2018-01-11 20:14 ` [for-4.16 PATCH v4 3/4] block: allow gendisk's request_queue registration to be deferred Mike Snitzer
2018-01-12  0:37   ` Bart Van Assche
2018-01-12  0:37     ` Bart Van Assche
2018-01-12  2:03     ` Mike Snitzer [this message]
2018-01-12  7:33   ` Ming Lei
2018-01-11 20:14 ` [for-4.16 PATCH v4 4/4] dm: fix awkward and incomplete 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=20180112020319.GC32298@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=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.