From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5491CC27.6080909@siemens.com> Date: Wed, 17 Dec 2014 19:32:07 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <5491B5E9.4030200@siemens.com> <5491C2CA.7000906@xenomai.org> <5491C179.2000600@siemens.com> <5491CB3F.2050509@xenomai.org> In-Reply-To: <5491CB3F.2050509@xenomai.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [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: Philippe Gerum , Xenomai On 2014-12-17 19:28, Philippe Gerum wrote: > On 12/17/2014 06:46 PM, Jan Kiszka wrote: >> On 2014-12-17 18:52, Philippe Gerum wrote: >>> On 12/17/2014 05:57 PM, Jan Kiszka wrote: >>>> 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). >>>> >>> >>> The legacy system_call vector is available unconditionally to x86_64. >>> Xenomai 3 is actually calling int80 unconditionally on mayday traps for >>> these reasons, i.e. always available and not suffering the long-mode >>> syscall registers issue. >> >> Only when setting CONFIG_IA32_EMULATION. That is typcially the case, but >> not necessarily. >> > > I mean: the "safe" Xenomai syscall form (the one that binds a process to > the real-time core in dual kernel mode) depends on this. Disabling int80 > is not an option in the current Xenomai implementation, mayday feature > put aside. Huh? Things worked fine here on X3 when trying out the effect of disabling IA32 emulation. Or do you mean 2.6? > > So this change would also break the Xenomai ABI (which is ok with x3, > but not an option for 2.6.4). Yes, 2.6 requires a compatible solution. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux