From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5491B5E9.4030200@siemens.com> Date: Wed, 17 Dec 2014 17:57:13 +0100 From: Jan Kiszka MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Xenomai] Mayday mechanism broken on x86-64 - simpler approach feasible? List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xenomai Hi, while porting the sigdebug test case to forge I noticed occasional crashes of the test after it received a watchdog signal. It turned out that the problem is in the way mayday works on x86-64: 1. sp/ip/ax of interrupted thread is saved 2. ip is set to mayday page 3. mayday page executes the mayday syscall via the syscall instruction 4. the syscall restores state on original state on return That that's the theory. Unfortunately the syscall instructions overwrites the cx register with the caller's instruction pointer. We could save it but there is no way to restore it on syscall return without significant changes to the Linux code in entry_64.S. x86-32 is fine as it uses the int80 path which does a full state recovery - but that is not available for 64-bit (only via ia32 compat, but that can be turned off). I was playing with a different approach: Set a flag that mayday is underway, let the interrupt context cause a fault (set ip to 0) and then fix that up if we are in mayday mode. Seems to work fine (after fixing some x86 ipipe issue) and would simplify the mayday logic apparently. So I'm wondering why that approach wasn't chosen initially? IOW, what am I missing? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux