Feature #2742
open
106: The gadget driver, char device number, and class device should be unregistered in reverse order of registration
Added by Evgeny Novikov over 12 years ago.
Updated almost 10 years ago.
Description
That is the correct order of function calls (in case of successful execution respectively):
class_create
alloc_chrdev_region
usb_gadget_register_driver
usb_gadget_unregister_driver
unregister_chrdev_region
class_destroy
This rule corresponds to
specific:usb:gadget class. 106_1a model will take care on this issue.
Links
Sample bugfix 2b9ec6c
Commit a7fa040 of our master branch adds support of 106_1a model with restriction that it doesn't take into account class_create/destroy to don't find an extra bug left after a fix presented in commit 2b9ec6c of the linux-stable branch.
With help of this model we can find a bug before the fix. After the fix 6Gb for BLAST allows to find safe.
- Subject changed from The gadget driver, char device number, and class device should be unregistered in reverse order of registration to 106: The gadget driver, char device number, and class device should be unregistered in reverse order of registration
- Priority changed from High to Normal
Reduce priority until we'll decide that it's high actually.
- Assignee changed from Evgeny Novikov to Mikhail Mandrykin
I guess that this is one of promising rules, so Mikhail may investigate it, complete it, create tests and make launches with different kernel versions.
Vadim has already investigated some results for 3.4 kernel (see here), has found some possible errors and some cases when the rule isn't correct or/and full.
The recent false positives analysis on the 3.4 linux kernel performed by Vadim showed alloc_chrdev_region may sometimes be called before create_class. Moreover searching the latest linux kernels on http://lxr.linux.no gave no results for functions usb_gadget_register_driver and usb_gadget_unregister_driver. So it seems they are not called or even declared anywhere in the latest kernels. Therefore I've revisited the model for a while splitting it to two different automata: class_create -- class_destroy and alloc_chrdev_region -- [usb_gadget_register_driver -- usb_gadget_unregister_driver] -- unregister_chrdev_region (including alternative functions class_register and register_chrdev_region). But it is still inappropriate for the latest kernels since the use of usb_gadget_register_driver and usb_gadget_unregister_driver.
It seems that by some reason usb_gadget_register_driver was changed with usb_gadget_probe_driver from 2.6.37 kernel, while usb_gadget_unregister_driver is used as early. So the rule is still actual (but has a bit another form).
Can class_create be called before usb_gadget_register_driver? What is about an unregistering order of calls?
Evgeny Novikov wrote:
Can class_create be called before usb_gadget_register_driver? What is about an unregistering order of calls?
In the previous launch there were no true nor false positives related to functions usb_gadget_register_driver or usb_gadget_unregister_driver, though it was on the 3.4 kernel where the function usb_gadget_probe_driver should be used instead (so false positives related to incomplete model should had been expected).
Current launch on linux 3.4.4 gave about 15 false positives related to incomplete model.
The functions unregister_chrdev_region and class_destroy сan apparently be called in reverse order because there was one false positive related to that. So currently the model checks for class (de)registration independently from chedev region and driver registration. Maybe this should be changed to forbid calling usb_gadget_probe_driver before class_create for instance.
- Status changed from Open to Resolved
- % Done changed from 0 to 90
Merged into master except regression task (requires linux-3.4 kernel).
- Status changed from Resolved to Open
Incomplete modle for alloc_chrdev_region(): it should set first argument to nonNULL in case of success.
It leads to false positive in drivers/iio/industrialio.ko:
ret = alloc_chrdev_region(&iio_devt, 0, IIO_DEV_MAX, "iio");
...
if (iio_devt)
unregister_chrdev_region(iio_devt, IIO_DEV_MAX);
- Description updated (diff)
Also available in: Atom
PDF