The RD device is sharing the same elv queue object across all of the ramdisks in the system. elv_register_queue() doesn't expect this. Each time the a ramdisk is registered the disk->queue->elevator is reinitialized. When elv_unregister_queue() is called , the first unregister works but the rest will trap the kernel. In my system there are 16 RAMDISKs and a single kobject with ref cnt = 1. The exit code tries to unregister this object 16 times.
Is there any problem with having each ramdisk have its own request_queue?
I don't know anything about how RD is using the elevator queues. I do believe some people use large numbers of disks so this might imply large numbers of queues. Do the RD elevator queues actually do anything or are they always empty? I found this problem because UML shuts the kernel down gracefully. A graceful shut down calls the exit functions on all of the drivers. The RD exit function fails when destroying the queues. You don't see this in a normal kernel reboot. A normal reboot doesn't bother shutting down the hardware individually. It just call bios reset which resets everything. UML can't do a BIOS reset since that would reset the host OS too. It might be worth asking on lkml if someone is familar with the queues.
Yeah, I would suggest just posting what you need to have happen and asking about the request_queues to lkml, because I really don't have any intimate knowledge of it.
rd is not using an elevator queue, however it has a block layer queue assigned to it like any other block driver.
What is the right fix for this? Should all ram disks be sharing the same queue object, and then modify elv_register_queue() to inc kobject ref counts if the object already exisits? Or should each RAM disk have it's own queue?
del_gendisk has changed since this patch was written, but it still looks like the patch has not been applied
Fixed in 2.5.70-bk