cvs commit: src/sys/arm/include asmacros.h atomic.h

[Olivier Houchard]

cognet      2007-12-07 22:08:02 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_6_3)
    sys/arm/include      asmacros.h atomic.h 
  Log:
  MFC:
  sys/arm/include/asmacros.h rev 1.7
  sys/arm/include/atomic.h rev 1.23
  
  Close a race.
  
  The RAS implementation would set the end address, then the start
  address.  These were used by the kernel to restart a RAS sequence if
  it was interrupted.  When the thread switching code ran, it would
  check these values and adjust the PC and clear them if it did.
  
  However, there's a small flaw in this scheme.  Thread T1, sets the end
  address and gets preempted.  Thread T2 runs and also does a RAS
  operation.  This resets end to zero.  Thread T1 now runs again and
  sets start and then begins the RAS sequence, but is preempted before
  the RAS sequence executes its last instruction.  The kernel code that
  would ordinarily restart the RAS sequence doesn't because the PC isn't
  between start and 0, so the PC isn't set to the start of the sequence.
  So when T1 is resumed again, it is at the wrong location for RAS to
  produce the correct results.  This causes the wrong results for the
  atomic sequence.
  
  The window for the first race is 3 instructions.  The window for the
  second race is 5-10 instructions depending on the atomic operation.
  This makes this failure fairly rare and hard to reproduce.
  
  Mutexs are implemented in libthr using atomic operations.  When the
  above race would occur, a lock could get stuck locked, causing many
  downstream problems, as you might expect.
  
  Also, make sure to reset the start and end address when doing a syscall, or
  a malicious process could set them before doing a syscall.
  
  Reviewed by: imp, ups (thanks guys)
  Approved by:    re (kensmith)
  Pointy hat to:  cognet
  
  Revision     Changes    Path
  1.4.10.1     +17 -13    src/sys/arm/include/asmacros.h
  1.8.2.3.8.1  +56 -27    src/sys/arm/include/atomic.h