Change Details

A series of three commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. The removal from xen_intr_port_to_isrc[] inside xen_intr_release_isrc() was wrong. If ->xi_port was invalid an entry would be incorrectly cleared. Previously this was mitigated by 0 being used as the invalid value for ->xi_port, but this will now manifest due to ~0 being used instead. I've concluded is_valid_evtchn() was serving to obscure, rather than usefully isolating anything. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Use isrc->xi_port whenever possible. This aids identifying duplicate sections, aiding potential merges. This is actually 3 commits being submitted as one, since they're closely related and were kind of small by themselves. Potentially they could be squashed on commit.

A series of commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. The removal from xen_intr_port_to_isrc[] inside xen_intr_release_isrc() was wrong. If ->xi_port was invalid an entry would be incorrectly cleared. Previously this was mitigated by 0 being used as the invalid value for ->xi_port, but this will now manifest due to ~0 being used instead. I've concluded is_valid_evtchn() was serving to obscure, rather than usefully isolating anything. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Locally this is broken into mini commits, since they're closely related and were kind of small by themselves. Potentially they could be squashed on commit.

A series of three commits stemming from the interaction between how indicies are best handled in C, versus the event channel API used by Xen. One test line was wrong. The result would be an overflow under some hard to produce conditions (not believed possible for attack), fix this. The removal from xen_intr_port_to_isrc[] inside xen_intr_release_isrc() was wrong. If ->xi_port was invalid an entry would be incorrectly cleared. Previously this was mitigated by 0 being used as the invalid value for ->xi_port, but this will now manifest due to ~0 being used instead. I've concluded is_valid_evtchn() was serving to obscure, rather than usefully isolating anything. As such remove this macro. There was some inconsistency when clearing xenisrc structures. Now use ~0 which is guaranteed invalid, instead of 0 which is reserved //not// invalid. Use isrc->xi_port whenever possible. This aids identifying duplicate sections, aiding potential merges. This is actually 3 commits being submitted as oneLocally this is broken into mini commits, since they're closely related and were kind of small by themselves. Potentially they could be squashed on commit.