Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 4 years ago

Last modified 19 months 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:

Description

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
  7. PREEMPTIBLE_HANDLER_USPACE does INLINE_SPILL_TO_WBUF because CANSAVE=0
  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 Changed 19 months ago by Jakub Jermář

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