Opened 11 years ago
Closed 10 years ago
#545 closed defect (fixed)
pio_enable cannot be undone
| Reported by: | Jiri Svoboda | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.6.0 |
| Component: | helenos/unspecified | Version: | mainline |
| Keywords: | Cc: | ||
| Blocker for: | Depends on: | ||
| See also: |
Description
There is no cleanup counterpart to pio_enable() function of ddi.h, so PIO-based drivers cannot perform complete cleanup.
Change History (3)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
I know it's not a serious issue, but still. A DDF-based driver (such as ata_bd) can handle more than one instance of the device and it is possible to dynamically add them and remove them (using devctl online/offline, for example). Even if I detach the driver from a particular device, the mapping will linger. Fortunately, re-enabling the pio succeeds.
Although a more theoretical case, successively trying to attach the driver to a series of addresses (the driver would do pio_enable() then try to probe the device and fail) could potentially leak a larger amount of address space mapping.
comment:3 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
pio_disable() support was merged in mainline,2214.
Can you give an example of where this would be a problem? pio_enable() makes changes only to the driver's address space or its I/O port access map. When the driver exits, all of this is destroyed anyway. Is your concern the inability to drop the "escalated privileges" or the "virtual address leak" in drivers that repeatedly enable and then "disable" some IO registers?