RE: Race in MSCP (ra/rx) driver

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Wednesday, August 26, 2020 at 8:48 AM, Mouse wrote:
> rx_putonline(struct rx_softc *rx)
> {
> ...
>         /* Poll away */
>         bus_space_read_2(mi->mi_iot, mi->mi_iph, 0);
>         if (tsleep(&rx->ra_state, PRIBIO, "rxonline", 100*100))
>                 rx->ra_state = DK_CLOSED;
> 
> In 1.4T, this code runs at IPL 0.  Unless it is called at elevated IPL in -current,
> there is a race: if the operation completes and interrupts before tsleep puts
> the thread to sleep, it will lose - it will sleep for 10000 ticks and then fail.
> Presumably most real hardware isn't that fast, but something like an MSCP
> interface backed by RAM or, in my case, a simulation, can trip this race.  (simh
> has comments saying, to rephrase from memory, that VMS works with an
> infinitely fast MSCP disk, but the BSDs don't - this is likely part of what's
> behind the latter.)

Simh may have a comment like that, but the MSCP device simulator does 
not implement infinitely fast I/O completion.  This is true for most devices, 
in most simulators, not just MSCP.  Software was written for real hardware 
and none of that completed I/O in 0 time, so simh's common device 
model provides a mechanism to specify a number of instructions to delay 
before I/O completion is signaled.  The MSCP device simulation support
true asynchronous I/O, and for this device the simulation framework still 
provides a concept of "at least n instruction delay" before I/O completion.

The completion delays defined in various simh devices have been set by 
observation of what work with the full range of operating systems that 
folks have run the simh VAX and VAX780 simulators.

- Mark