search for: gendisk

Hi Jens, this series removes the revalidate_disk() function, which has been a really odd duck in the last years. The prime reason why most people use it is because it propagates a size change from the gendisk to the block_device structure. But it also calls into the rather ill defined ->revalidate_disk method which is rather useless for the callers. So this adds a new helper to just propagate the size, and cleans up all kinds of mess around this area. Follow on patches will eventuall kill of ->...

.../genhd.h | 1 + 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/block/genhd.c b/block/genhd.c index 8e1bfa1..9b66953 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -506,12 +506,10 @@ static int exact_lock(dev_t devt, void *data) return 0; } -static void register_disk(struct gendisk *disk) +static void register_disk(struct gendisk *disk, bool gen_uevent) { struct device *ddev = disk_to_dev(disk); struct block_device *bdev; - struct disk_part_iter piter; - struct hd_struct *part; int err; ddev->parent = disk->driverfs_dev; @@ -563,6 +561,22 @@ static void regis...

...9 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -595,9 +595,10 @@ exit: * This function registers the partitioning information in @disk * with the kernel. * - * FIXME: error handling + * RETURNS: + * 0 on success, -errno on failure. */ -void device_add_disk(struct device *parent, struct gendisk *disk) +int device_add_disk(struct device *parent, struct gendisk *disk) { struct backing_dev_info *bdi; dev_t devt; @@ -613,10 +614,8 @@ void device_add_disk(struct device *parent, struct gendisk *disk) disk->flags |= GENHD_FL_UP; retval = blk_alloc_devt(&disk->part0, &dev...

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

...-blkfront.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2f22874..5d45688 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode) mutex_lock(&blkfront_mutex); bdev = bdget_disk(disk, 0); - bdput(bdev); if (bdev->bd_openers) goto out; @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode) } out: + bdput(bdev); mutex_unlock(&blkfront_mutex); retur...

...-blkfront.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2f22874..5d45688 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode) mutex_lock(&blkfront_mutex); bdev = bdget_disk(disk, 0); - bdput(bdev); if (bdev->bd_openers) goto out; @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode) } out: + bdput(bdev); mutex_unlock(&blkfront_mutex); retur...

On Wed, 17 Aug 2016 15:15:06 +0800 Fam Zheng <famz at redhat.com> wrote: > @@ -613,10 +614,8 @@ void device_add_disk(struct device *parent, struct gendisk *disk) > disk->flags |= GENHD_FL_UP; > > retval = blk_alloc_devt(&disk->part0, &devt); > - if (retval) { > - WARN_ON(1); > - return; > - } > + if (retval) > + goto fail; > disk_to_dev(disk)->devt = devt; > > /* ->major and ->fi...

On Wed, 17 Aug 2016 15:15:06 +0800 Fam Zheng <famz at redhat.com> wrote: > @@ -613,10 +614,8 @@ void device_add_disk(struct device *parent, struct gendisk *disk) > disk->flags |= GENHD_FL_UP; > > retval = blk_alloc_devt(&disk->part0, &devt); > - if (retval) { > - WARN_ON(1); > - return; > - } > + if (retval) > + goto fail; > disk_to_dev(disk)->devt = devt; > > /* ->major and ->fi...

On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > Documentation/kobject.txt: > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > This should be done only after any attributes or children of the kobject > > have been initialized properly, as userspace will instantly start to look > > for them when this call happens. > >

On Wed, 06/29 23:24, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > > Documentation/kobject.txt: > > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > > This should be done only after any attributes or children of the kobject > > > have been initialized properly, as userspace will instantly

On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote: > also more code and less flexible IMO. For example, we need at least two > variants, for attribute_group and device_attribute separately, right? Yes, or maybe just a calling convention that just passes both.

On Wed, 06/29 23:38, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote: > > also more code and less flexible IMO. For example, we need at least two > > variants, for attribute_group and device_attribute separately, right? > > Yes, or maybe just a calling convention that just passes both. OK, I can look into that, but I'm not sure about

On Wed, 06/29 23:24, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 09:59:41AM +0800, Fam Zheng wrote: > > Documentation/kobject.txt: > > > Use the KOBJ_ADD action for when the kobject is first added to the kernel. > > > This should be done only after any attributes or children of the kobject > > > have been initialized properly, as userspace will instantly

On Wed, 06/29 23:38, Christoph Hellwig wrote: > On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote: > > also more code and less flexible IMO. For example, we need at least two > > variants, for attribute_group and device_attribute separately, right? > > Yes, or maybe just a calling convention that just passes both. OK, I can look into that, but I'm not sure about

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

...8:23 +0800 Fam Zheng <famz at redhat.com> wrote: > On Wed, 08/17 10:49, Cornelia Huck wrote: > > On Wed, 17 Aug 2016 15:15:06 +0800 > > Fam Zheng <famz at redhat.com> wrote: > > > > > @@ -613,10 +614,8 @@ void device_add_disk(struct device *parent, struct gendisk *disk) > > > disk->flags |= GENHD_FL_UP; > > > > > > retval = blk_alloc_devt(&disk->part0, &devt); > > > - if (retval) { > > > - WARN_ON(1); > > > - return; > > > - } > > > + if (retval) > > > + g...