Bug #1839
openLdv-manager can't find bug in driver
0%
Description
In driver gpio/pca953x.c was added artificial bug on 32 rule (lock-unlock), but result of cheking was safe.
Checked various changes, one of them:
static void pca953x_irq_bus_sync_unlock(struct irq_data *d) {
struct pca953x_chip chip = irq_data_get_irq_chip_data(d);
uint16_t new_irqs;
uint16_t level;
mutex_lock(&chip->irq_lock);
/ Look for any newly setup interrupt */
new_irqs = chip->irq_trig_fall | chip->irq_trig_raise;
new_irqs &= ~chip->reg_direction;while (new_irqs) {
level = __ffs(new_irqs);
pca953x_gpio_direction_input(&chip->gpio_chip, level);
new_irqs &= ~(1 << level);
}// mutex_unlock(&chip->irq_lock);
}
Files
Updated by Pavel Shved almost 13 years ago
- Status changed from New to Feedback
What function did you make the change to?
Will it compile with the default main() generator?
What happens if you add the bug in the first function your generated main invokes?
Updated by Ilja Zakharov almost 13 years ago
At the moment I wrote patterns for paired functions in all two structures in driver, it seems that problem of incorrect determination of artificial bugs is in wrong modeling of drivers with two or more structures. This assumption is confirmed by addition tests and false-positives in "clean" driver without any changes that appeared while i tried to run driver separate from kernel.
Updated by Pavel Shved almost 13 years ago
If you have a separate driver, please, attach it, write the command line how you invoke the tools, the result you've got, and the result you expected, so that others could reproduce it and fix it if applicable.
(This applies not to this bug only).
Updated by Ilja Zakharov almost 13 years ago
- File pca953x.tar.bz2 pca953x.tar.bz2 added
i run as usual:
ldv-manager "LDV_DEBUG=100" "envs=linux-2.6.39.tar.bz2" "drivers=pca953x.tar.bz2" "name=x1" "rule_models=32_7 39_7 68_1 08_1"
I got false-positive result "unsafe" on 32_7 rule, this false-positive connected with incorrect order of using functions from structures irq_chip and i2c_driver. This bug can't be fixed by configuration only as i understand, because of absence of opportunity in configuration file to control order of functions from different structures together.
Updated by Ilja Zakharov almost 13 years ago
Simple scheme of using strucures and their functions in this driver:
init ---> struct 12c_driver:
--> calling probe ---> struct irq_chip
---> various functions from struct irq_chip
--> calling remove.
According this scheme may be appropriate to use functions from different structures using chain-order of declaration structures:
firstly functions from structure that is used in init()
Then according mentions of second structure in functions of previous.
Updated by Pavel Shved almost 13 years ago
I can't reproduce this bug with the driver attached. It reports "safe" on all four rules. My toolset version is 32b02f5f. Do you use a non-standard config or something?
Updated by Pavel Shved almost 13 years ago
- Status changed from Feedback to Open
- Platform set to Linux x86
The bug is only reproducible on 32-bit architecture, as it seemingly turns on the option CONFIG_GPIO_PCA953X_IRQ by default.