Feature #2751
open108: Driver callback functions should always return non positive values
0%
Description
I guess that this isn't absolute truth indeed... But it seems, that at least some classes of callbacks, for instance, opens, should do.
This issue belongs to specific:check_ret_val class. Model 108_1a will be devoted for it.
Updated by Evgeny Novikov about 12 years ago
Commit 4234c4e of our master branch makes a first step in this direction, it verifies that slip_open function from drivers/net/slip.c doesn't return positive integer number. This allows to check 1b0b0ac commit of linux-stable branch. But still much work is required for the given issue.
Updated by Alexey Khoroshilov about 12 years ago
- Subject changed from Driver callback functions should always return non positive values to 108: Driver callback functions should always return non positive values
Updated by Evgeny Novikov almost 12 years ago
- Priority changed from High to Normal
Reduce priority until we'll decide that it's high actually.
Updated by Evgeny Novikov almost 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 at least.
Updated by Mikhail Mandrykin over 11 years ago
Note about idea initially appeared for rule 119_1 (134_1? Issue #3313). There probe() function should be verified to return error code in case some critical function call (e.g. driver registration function call, driver structure allocation and /or initialization etc.) inside it fails. I.e. probe() should propagate error codes returned by such functions or at least not return success in such cases.