From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54DCE08F.6050304@siemens.com> Date: Thu, 12 Feb 2015 18:19:11 +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> <5491CC27.6080909@siemens.com> <5491D196.3040309@xenomai.org> <54D0E961.4060705@xenomai.org> <54DCD68F.5020005@siemens.com> <54DCDC98.5070402@siemens.com> <54DCDDC7.5060700@xenomai.org> <54DCDFD5.9090202@siemens.com> <54DCE07F.5020902@xenomai.org> In-Reply-To: <54DCE07F.5020902@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 2015-02-12 18:18, Philippe Gerum wrote: > On 02/12/2015 06:16 PM, Jan Kiszka wrote: >> On 2015-02-12 18:07, Philippe Gerum wrote: >>> On 02/12/2015 06:02 PM, Jan Kiszka wrote: >>>> On 2015-02-12 17:36, Jan Kiszka wrote: >>>>>> As I mentioned earlier, I'd rather fix the MAYDAY implementation for >>>>>> x86_64 instead of forking the implementation between MMU-enabled and >>>>>> MMU-less architectures, also affecting powerpc, arm and x86_32 in the >>>>>> same move. Fortunately, the current implementation allows very specific >>>>>> tweaks to be applied on a per-architecture basis. This one fixes the >>>>>> issue for Cobalt on x86_64, and could be easily backported to 2.6.x: >>>>>> >>>>>> http://git.xenomai.org/xenomai-3.git/commit/?h=next&id=6db20901963d634b9786467c711c2ba526db48a2 >>>>> >>>>> Looks almost good - except for the detail that some bits of the >>>>> instruction pointer are lost on return from the syscall (int vs. long >>>>> return type). Patches in the making. >>>> >>>> Will take longer - I need to convert all cobalt syscalls. >>>> >>>> We have a sleeping bug there, though likely not seen in practice, with >>>> syscalls returning values > INT_MAX (size_t...). The problem is that >>>> handle_head/root_syscall only forwarded 32-bits so far. >>>> >>> >>> You mean this, and all the implications of it? >>> >>> diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c >>> index 6a9a02c..99b86a4 100644 >>> --- a/kernel/cobalt/posix/syscall.c >>> +++ b/kernel/cobalt/posix/syscall.c >>> @@ -73,9 +73,9 @@ >>> /* Shorthand for oneway trap - does not return to call site. */ >>> #define __xn_exec_oneway __xn_exec_norestart >>> >>> -typedef int (*cobalt_syshand)(unsigned long arg1, unsigned long arg2, >>> - unsigned long arg3, unsigned long arg4, >>> - unsigned long arg5); >>> +typedef long (*cobalt_syshand)(unsigned long arg1, unsigned long arg2, >>> + unsigned long arg3, unsigned long arg4, >>> + unsigned long arg5); >>> >>> static void prepare_for_signal(struct task_struct *p, >>> struct xnthread *thread, >>> >> >> Exactly. >> >> Just done with the mechanics, crossing fingers it won't break things subtly. >> > > Ok. While we are at it, we should get rid of the syscall return type in > the COBALT_SYSCALL[_DECL] macro helpers, this is pointless. Jep, that's what I did - hard-wired it to long. First tests look good, just need to split things up into 3 or 4 patches now. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux