similar to: [PATCH 0/4] block: move sd_format_disk_name() into block core as disk_name_format()

On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote: > Hi, > > The current virtblk's naming algorithm just supports 26^3 > disks. If there are mass of virtblks(exceeding 26^3), there > will be disks with the same name. > > According to "sd_format_disk_name()", I add function > "virtblk_name_format()" for virtblk to support mass of >

On Wed, Mar 28, 2012 at 02:54:43PM +0800, Ren Mingxin wrote: > Hi, > > The current virtblk's naming algorithm just supports 26^3 > disks. If there are mass of virtblks(exceeding 26^3), there > will be disks with the same name. > > According to "sd_format_disk_name()", I add function > "virtblk_name_format()" for virtblk to support mass of >

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

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

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

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

On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: > On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: > > Hi All, > > > > We've had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel

On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote: > On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: > > Hi All, > > > > We've had a report[1] of the virt_blk driver causing a lot of spew > > because it's calling a sleeping function from an invalid context. The > > backtrace is below. This is with kernel

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Convert the S_<FOO> symbolic permissions to their octal equivalents as using octal and not symbolic permissions is preferred by many as more readable. see: https://lkml.org/lkml/2016/8/2/1945 Done with automated conversion via: $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace <files...> Miscellanea: o Wrapped modified multi-line calls to a single line where

Convert the S_<FOO> symbolic permissions to their octal equivalents as using octal and not symbolic permissions is preferred by many as more readable. see: https://lkml.org/lkml/2016/8/2/1945 Done with automated conversion via: $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace <files...> Miscellanea: o Wrapped modified multi-line calls to a single line where

Do not unregister the major at device remove, since there might be another device instances around. (qemu) pci_del 0 11 (qemu) ACPI: PCI interrupt for device 0000:00:0b.0 disabled (qemu) pci_del 0 10 (qemu) ------------[ cut here ]------------ WARNING: at block/genhd.c:126 unregister_blkdev+0x74/0x9e() ACPI: PCI interrupt for device 0000:00:0a.0 disabled Signed-off-by: Marcelo Tosatti

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

The current virtio block's naming algorithm just supports 18278 (26^3 + 26^2 + 26) disks. If there are mass of virtio blocks, there will be disks with the same name. Based on commit 3e1a7ff8a0a7b948f2684930166954f9e8e776fe, I add function "virtblk_name_format()" for virtio block to support mass of disks naming. Signed-off-by: Ren Mingxin <renmx at cn.fujitsu.com> ---

When virtio block device is removed, index does not get decremented. When another virtio disk is attached it uses the next device letter to the one that is suppose to be available. Signed-off-by: Takuma Umeya <tumeya at redhat.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 6ecf89c..730e7af 100644 --- a/drivers/block/virtio_blk.c +++

When virtio block device is removed, index does not get decremented. When another virtio disk is attached it uses the next device letter to the one that is suppose to be available. Signed-off-by: Takuma Umeya <tumeya at redhat.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 6ecf89c..730e7af 100644 --- a/drivers/block/virtio_blk.c +++