Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 6 years ago

Closed 5 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 Changed 6 years ago by Jakub Jermář

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 Changed 6 years ago by Jiri Svoboda

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 Changed 5 years ago by Jakub Jermář

Resolution: fixed
Status: newclosed

pio_disable() support was merged in mainline,2214.

Note: See TracTickets for help on using tickets.