dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/24/88)
A friend of mine got caught by this one: BSET is atomic, right? OR.w #1,memory? wrong Guess what? The 68020 has no compunction for interrupting an instruction in the middle of its execution. So all those supposedly atomic single-instruction operations people have probably been doing, and not surrounding them with Forbid()/Permit(), create windows of vulnerability if you've got a 68020. -Matt
mph@rover.UUCP (Mark Huth) (06/25/88)
In article <8806240024.AA11802@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > A friend of mine got caught by this one: > > BSET is atomic, right? OR.w #1,memory? > > wrong > > Guess what? The 68020 has no compunction for interrupting an > instruction in the middle of its execution. > > So all those supposedly atomic single-instruction operations people >have probably been doing, and not surrounding them with Forbid()/Permit(), >create windows of vulnerability if you've got a 68020. Well, I'm not sure what you mean by interrupting an instruction. The 68020 manual, on page 5-27 (1984 ed.) states that the exception processing for an interrupt begins at the next instruction boundary! There are cases where the 68020 will relinquish the bus without completing the data transfers for an instruction. There are no promises made that a read/modify/write instruction is indivisible except for TAS, CAS, and CAS2. If you need to synchronize multi-processors use the correct instructions. Certain exceptions will be taken in the middle of an instruction, but cause no problems as execution will resume (if possible) in the middle of the instruction once the exception is handled. If you have analyzer traces that demonstrate that an interrupt context change occurs in the middle of an instruction, we would like to see them at Motorola. Mark Huth
nw@palladium.UUCP (Neil W.) (06/25/88)
In article <8806240024.AA11802@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > A friend of mine got caught by this one: > > BSET is atomic, right? OR.w #1,memory? > > wrong > > Guess what? The 68020 has no compunction for interrupting an > instruction in the middle of its execution. > This isn't correct, unless I misunderstand what you are saying. The 68020 samples interrupts generated by external devices *only* on instruction boundaries; you will never see an interrupt handler invoked in the middle of read and write cycles of any instruction. On the Amiga, you will *never* see a process switch occur in the middle of such an instruction. One exception :-) to this rule is the Bus Error exception, aka "page fault" on systems with an MMU. The Bus Error exception can in fact occur on *any* bus cycle. Thus, this sequence of operations is possible: - BSET reads memory - BSET modifies bit internally - BSET writes memory -- but wait! the write fails due to bus error, because the page has been marked read-only and this is a UNIX box with copy-on-write fork :-) - UNIX kernel copies the page, marks it writable, and is preparing to return to your process. At this point, if an external interrupt occurs, the interrupt handler would in fact be able to modify the very same location that the BSET instruction was trying to modify. If this were to happen, then when the kernel returns from the bus error exception, the write cycle of the BSET instruction will pick up where it left off -- any modifications to the location made by the interrupt handler may in fact get trashed. This happens because the bus error exception works on a cycle-by-cycle basis, not on an instruction-by-instruction basis. A similar thing can happen with signal handlers on UNIX boxes. Signal handlers get invoked by Berkeley-derived UNIX in the tail end of the processor exception code. Thus, it is possible that a naive port of the vax "trap.c" code to a 680x0 box might make it possible for a user signal handler to be invoked "in the middle" of an instruction. I consider this to be a bug in the kernel, because it exposes a macro-inconsistent state of the machine to the user process signal handler. Things get especially strange if the faulted instruction was a JSR that has to grow the stack. > So all those supposedly atomic single-instruction operations people >have probably been doing, and not surrounding them with Forbid()/Permit(), >create windows of vulnerability if you've got a 68020. I don't think so, unless someone has ported a buggy UNIX implementation to their Amigas :-) -- Neil Webber / Epoch Systems, Marlboro MA / (617) 481-3717 {harvard!cfisun, linus!alliant}!palladium!nw
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (06/30/88)
In article <8806240024.AA11802@cory.Berkeley.EDU>, Matt Dillon (dillon@CORY.BERKELEY.EDU) writes: > A friend of mine got caught by this one: > > BSET is atomic, right? OR.w #1,memory? > > wrong > > Guess what? The 68020 has no compunction for interrupting an > instruction in the middle of its execution. > > So all those supposedly atomic single-instruction operations people > have probably been doing, and not surrounding them with Forbid()/Permit(), > create windows of vulnerability if you've got a 68020. There is nothing in the chip that can prevent DMA hardware from getting in between the read of the memory location and the write back to that location, changing the contents of memory (which then gets clobbered by the results of the instruction). There is a line out of the processor (RMC*) which indicates that memory should not be altered during TAS (test and set) and CAS and CAS2 (compare and swap) instructions. Note that the memory system must be able to respond to this line, though! Steve Rice ----------------------------------------------------------------------------- * Every knee shall bow, and every tongue confess that Jesus Christ is Lord! * new: stever@videovax.tv.Tek.com [phone (503) 627-1320] old: {decvax | hplabs | uw-beaver}!tektronix!videovax!stever