[Bug 1000170] SuperH context switch code vulnerable to stack corruption by ISR

[bugzilla at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000170


michaelb@ieee.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |MODIFIED




------- Additional Comments From michaelb@ieee.org  2005-19-04 10:29 -------
After testing the revised patch, I'm not seeing any strange SR values, nor any 
other new problems, so it seems ok. 
 
However, as an aside on the merits of this revised vs the initial version of 
the patch, consider the case when you are switching from thread T1 to thread 
T2. By updating SP before modifying SR, you eliminate the possibility of an 
interrupt permitted by T2's (presumably more permissive) interrupt mask from 
running on T1's stack. However if T1 has the more permissive interrupt mask, 
then updating SR before SP means that you run the risk of executing interrupts 
permitted by T2 (but not T1) on T1's stack. Admittedly, the scenario that the 
revised patch deals with is more likely to be a problem in practice, since the 
interrupts may be pending and ready to cause havoc when the window opens, 
rather than having to actually occur when the window is open, but I'm quite 
leery about employing such reasoning to figure out what will be a problem in 
practice and what won't after having been bitten (or should that be mauled?) by 
this bug. 
 
It seems to me to be an either/or sort of proposition -- depending on the 
relative order of the SR and SP updates, either T1 or T2 will be open to 
interrupts it thinks it has masked out making use of its stack. To resolve this 
would seem to require the update of SR and SP to be a single atomic operation, 
which in this context means disabling interrupts while the SR and SP update 
occurs. You may or may not find this too drastic for your tastes -- I know it 
is for mine, but then again I'm not such a huge fan of having per thread 
interrupt masks anyway (couldn't think of a reasonable use case) so mine is 
probably not the most useful opinion to solicit on this matter. 



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.