search for: kobj_add

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 is not the only driver tha...

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 is not the only driver tha...

On Wed, Jun 29, 2016 at 6:59 PM, Fam Zheng <famz at redhat.com> wrote: > It is documented that KOBJ_ADD should be generated after the object's > attributes and children are ready. We can achieve this with the new > disk_gen_uevents interface. > > Signed-off-by: Fam Zheng <famz at redhat.com> > --- > arch/powerpc/sysdev/axonram.c | 3 ++- > 1 file changed, 2 insertions...

On Wed, Jun 29, 2016 at 6:59 PM, Fam Zheng <famz at redhat.com> wrote: > It is documented that KOBJ_ADD should be generated after the object's > attributes and children are ready. We can achieve this with the new > disk_gen_uevents interface. > > Signed-off-by: Fam Zheng <famz at redhat.com> > --- > arch/powerpc/sysdev/axonram.c | 3 ++- > 1 file changed, 2 insertions...

...63,6 +561,22 @@ static void register_disk(struct gendisk *disk) exit: /* announce disk after possible partitions are created */ dev_set_uevent_suppress(ddev, 0); + if (gen_uevent) + disk_gen_uevents(disk); +} + +/** + * disk_gen_uevents + * @disk - the disk to generate uevent + * + * Generate KOBJ_ADD uevents on the disk and partitions. + */ +void disk_gen_uevents(struct gendisk *disk) +{ + struct device *ddev = disk_to_dev(disk); + struct disk_part_iter piter; + struct hd_struct *part; + kobject_uevent(&ddev->kobj, KOBJ_ADD); /* announce possible partitions */ @@ -571,6 +585,7 @@ e...

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. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in...

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. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in...

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > 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. > > > > This race condition can be easily reproduced by ho...

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > 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. > > > > This race condition can be easily reproduced by ho...

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: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

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 sysfs entries...

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 sysfs entries...

On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > 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. > > This race condition can be easily reproduced by hot plugging a number of &g...

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. > > Unfortunately it see...

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 start to look > > > for them when this call happens. > > >...

It is documented that KOBJ_ADD should be generated after the object's attributes and children are ready. We can achieve this with the new disk_gen_uevents interface. Signed-off-by: Fam Zheng <famz at redhat.com> --- arch/powerpc/sysdev/axonram.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/a...

It is documented that KOBJ_ADD should be generated after the object's attributes and children are ready. We can achieve this with the new disk_gen_uevents interface. Signed-off-by: Fam Zheng <famz at redhat.com> --- drivers/block/aoe/aoeblk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/driv...

Previously after device_add_disk returns, the KOBJ_ADD uevent is already emitted. Adding attributes after that is a poor usage of kobject, and in practice may result in race conditions with userspace, for example udev checks availability of certain attributes and initializes /dev entries conditionally. device_add_disk can handle adding attribute group...

Previously after device_add_disk returns, the KOBJ_ADD uevent is already emitted. Adding attributes after that is a poor usage of kobject, and in practice may result in race conditions with userspace, for example udev checks availability of certain attributes and initializes /dev entries conditionally. device_add_disk can handle adding attribute group...