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:


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 Jakub Jermář, 11 years ago

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?

comment:2 by Jiri Svoboda, 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 Jakub Jermář, 10 years ago

Resolution: fixed
Status: newclosed

pio_disable() support was merged in mainline,2214.

Note: See TracTickets for help on using tickets.