Bug #1839
open
Ldv-manager can't find bug in driver
Added by Ilja Zakharov about 13 years ago.
Updated about 13 years ago.
Category:
Environment Generation
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
- 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?
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.
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).
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.
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.
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?
- 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.
Also available in: Atom
PDF