Feature #2742
open106: The gadget driver, char device number, and class device should be unregistered in reverse order of registration
90%
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
Updated by Evgeny Novikov over 12 years ago
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.
Updated by Alexey Khoroshilov over 12 years ago
- 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
Updated by Evgeny Novikov over 12 years ago
- Priority changed from High to Normal
Reduce priority until we'll decide that it's high actually.
Updated by Evgeny Novikov over 12 years ago
- 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.
Updated by Mikhail Mandrykin about 12 years ago
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
.
Updated by Evgeny Novikov about 12 years ago
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?
Updated by Mikhail Mandrykin about 12 years ago
Evgeny Novikov wrote:
Can
class_create
be called beforeusb_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.
Updated by Mikhail Mandrykin about 12 years ago
- Status changed from Open to Resolved
- % Done changed from 0 to 90
Merged into master except regression task (requires linux-3.4 kernel).
Updated by Alexey Khoroshilov over 11 years ago
- 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);