Opened 9 years ago

Last modified 7 years ago

#607 new defect

Nested traps should probably lower GL too to avoid register corruption

Reported by: Jakub Jermář Owned by: Jakub Jermář
Priority: major Milestone:
Component: helenos/kernel/sparc64 Version: mainline
Keywords: sun4v Cc: rimskyp@…
Blocker for: Depends on:
See also:


On sun4v, the active set of global registers is determined by the GL (global level) register, similarly to the TL (trap level) register, it will be increased by one when a (nested) trap occurs. The UA2005 architecture defines a maximum value for this register (MAXPGL) and the UltraSPARC T1 processor defines MAXPGL=2. Attempts to store a greater value to GL will result in storing MAXPGL.

Now, when handling a nested trap, HelenOS lowers the TL value to avoid overflowing it and also to support the preemptible_trap handler, but it does not lower the GL value. It seems to me like there is a potential for corrupting some of the global registers at GL=2:

  1. executing in uspace: TL=0, GL=0
  2. the uspace code executes the SAVE instruction while CANSAVE=0
  3. window_spill trap: TL=1, GL=1
  4. trying to save the window to the uspace stack, which is not mapped
  5. fast_data_access_MMU_miss: TL=2, GL=2
  6. need to call preemptible_handler, lower TL: TL=1, GL=2
  8. let's assume the wbuf is not mapped by DTLB, so we trap: TL=2, GL=2 (!)

At this point, the nested DTLB trap is sharing the globals at GL 2 with the preemptible handler. When the nested trap returns, chances are that some globals will be corrupted.

Change History (1)

comment:1 by Jakub Jermář, 7 years ago

Milestone: 0.7.1
Note: See TracTickets for help on using tickets.