Bug 8174
| Summary: | ohci1394 does not atomically update config ROM | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Stefan Richter (stefanr) |
| Component: | IEEE1394 | Assignee: | Stefan Richter (stefanr) |
| Status: | REJECTED WILL_NOT_FIX | ||
| Severity: | low | CC: | protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | all | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 10046 | ||
> Do not run ohci_set_hw_config_rom() if there are already both
> new + old DMA areas.
Correction: If there are already both new + old DMA areas, IOW if
ohci_set_hw_config_rom() is re-entered before the bus reset was performed, point
ConfigROMmap to the newest DMA area and free the not-anymore-so-new DMA area.
This bug is a candidate for WILL_NOT_FIX, since the alternative drivers from Kristian H I will update the status of this bug once we got a better impression on how Kristian's drivers fare in practice. (They are now available to the broader public through Linus' 2.6.22-rc1 and later and already have replaced the old ieee1394 drivers in Fedora 7's kernel.) There are currently no resources to fix this in drivers/ieee1394/. drivers/firewire/ does not feature this problem. |
ohci_set_hw_config_rom() does not follow the mandatory procedure described in OHCI 1.1 clause 5.5.6. This may expose invalid configuration ROM data to external FireWire peers. How to solve this: - Copy new ROM data into a separate DMA area and point ConfigROMmap to it. - Keep track of existence of old and new DMA area. Do not run ohci_set_hw_config_rom() if there are already both new + old DMA areas. - In a bus reset interrupt event, free the old DMA area if there is one.