On 2021/08/11 1:02, hch@xxxxxxxxxxxxx wrote: > On Tue, Aug 10, 2021 at 11:03:41AM +0000, Damien Le Moal wrote: >>>> + * Dummy release function to make kobj happy. >>>> + */ >>>> +static void blk_cranges_sysfs_nop_release(struct kobject *kobj) >>>> +{ >>>> +} >>> >>> How do we ensure the kobj is still alive while it is accessed? >> >> q->sysfs_lock ensures that. This mutex is taken whenever revalidate registers >> new ranges (see blk_queue_set_cranges below), and is taken also when the ranges >> are unregistered (on revalidate if the ranges changed and when the request queue >> is unregistered). And blk_crange_sysfs_show() takes that lock too. So the kobj >> cannot be freed while it is being accessed (the sysfs inode lock also prevents >> it since kobj_del() will take the inode lock). > > Does it? It only protects the access inside of it, but not the object > lifetime. Alloc & free of the cranges structure (the top kobj) are under the q->sysfs_lock, always. With the accesses also under that same lock, this is mutually exclusive and all protected. Furthermore, the crange kobj_add()/kobj_del() do a kobj_get()/kobj_put() on the parent kobj, which is the request queue kobj. So the queue cannot go away under the crange struct. I can add a kobj_get/put for the crange struct, but I really do not see the need for that. Or am I missing something ? >>>> +void blk_queue_set_cranges(struct gendisk *disk, struct blk_cranges *cr) >>> >>> s/blk_queue/disk/ >> >> Hmmm... The argument is a gendisk, but it is the request queue that is modified. >> So following other functions like this, isn't blk_queue_ prefix better ? > > Do we have blk_queue_ functions that take a gendisk anywhere? The > ones I noticed (and the ones I've recently added) all use disk_. The only one I can find is blk_queue_set_zoned(), which we could probably rename to disk_set_zoned(). There are blk_revalidate_disk_zones() and blkdev_nr_zones() which also take a gendisk and could probably be renamed as disk_revalidate_zones() and disk_nr_zones() for consistency. Will rename to disk_set_cranges(). -- Damien Le Moal Western Digital Research