From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5491C242.1000505@siemens.com> Date: Wed, 17 Dec 2014 18:49:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <5491B5E9.4030200@siemens.com> <5491BB1B.7020306@xenomai.org> <20141217171734.GE2012@hermes.click-hack.org> <5491BF2F.7060706@siemens.com> <20141217174546.GI2012@hermes.click-hack.org> In-Reply-To: <20141217174546.GI2012@hermes.click-hack.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: Gilles Chanteperdrix Cc: Xenomai On 2014-12-17 18:45, Gilles Chanteperdrix wrote: > On Wed, Dec 17, 2014 at 06:36:47PM +0100, Jan Kiszka wrote: >> On 2014-12-17 18:17, Gilles Chanteperdrix wrote: >>> On Wed, Dec 17, 2014 at 06:19:23PM +0100, 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. >>> >>> Maybe we can restore it in xnarch_fixup_mayday, if nothing touches >>> it ? >> >> The problem is that cx is mangled again on preparing sysret - we are in >> a syscall return path at that point, but we need an interrupt/exception >> path in fact. > > ARM had a similar issue with the register holding the syscall return > value, the fix was to return __xn_reg_rval(regs) in > the mayday syscall, is not this fix working for x86? How is cx > mangled exactly? rcx holds the ip of the context we call from / return to. So the return path loads cx with the ip value saved in the register set on the stack. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux