From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8C2B08.8080907@domain.hid> Date: Mon, 01 Mar 2010 22:00:56 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B86EDC2.7010905@domain.hid> <4B86FCBB.10203@domain.hid> <4B86FFA0.3000403@domain.hid> <4B870134.2040802@domain.hid> <4B87FC70.90903@domain.hid> <4B8C2490.1040604@domain.hid> <4B8C25B9.8090705@domain.hid> <4B8C26F7.3020306@domain.hid> <4B8C2797.2000501@domain.hid> <4B8C29E1.7070404@domain.hid> In-Reply-To: <4B8C29E1.7070404@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] mlockall error after calling mlockall() List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Charlton, John wrote: >>>>>> I added some printk output to the cond.c file in xenomai-2.5.1 and it shows that xnsync_sleep_on returned -ETIMEDOUT as it should: >>>>>> Xenomai: registered exported object M1-1908 (mutexes) >>>>>> Xenomai: registered exported object C1-1908 (condvars) >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -110 >>>>>> xnsynch_sleep_on returned: -4 >>>>>> Xenomai: native: cleaning up cond "C1-1908" (ret=0). >>>>>> Xenomai: unregistered exported object C1-1908 (condvars) >>>>>> Xenomai: native: cleaning up mutex "M1-1908" (ret=0). >>>>>> Xenomai: unregistered exported object M1-1908 (mutexes) >>>>>> Xenomai: POSIX: destroyed thread df5a0800 >>>>>> >>>>>> I put the printk on line cond.c:433 after err is set in rt_cond_wait_prologue(): >>>>>> >>>>>> info = xnsynch_sleep_on(&cond->synch_base, >>>>>> timeout, timeout_mode); >>>>>> if (info & XNRMID) >>>>>> err = -EIDRM; /* Condvar deleted while pending. */ >>>>>> else if (info & XNTIMEO) { >>>>>> err = -ETIMEDOUT; /* Timeout. */ >>>>>> } >>>>>> else if (info & XNBREAK) { >>>>>> err = -EINTR; /* Unblocked. */ >>>>>> } >>>>>> printk(KERN_DEBUG "xnsynch_sleep_on returned: %d\n", err); >>>>>> >>>>>> I put a printk in rt_cond_wait_inner() which is called directly by rt_cond_wait() from user mode but did not see the output in the dmesg output for that one. >>>>> One of our problems is the prologue/epilogue split up (both in kernel >>>>> and user space): the epilogue can eat the error code or the prologue, >>>>> including the -ETIMEDOUT. >>>> Ah. My fault. Looks user-space is Ok though. Only kernel-space has a >>>> problem. >>>> >>> Both are affected. >>> >>> Could you help me with what issues >>> 97323b3287b5ee8cad99a7fa67cd050bc51f76c4 should fix? >> Ah, restart after RT-signals! So far we blocked on the concluding >> rt_mutex_lock without breaking out to user space, now we have to loop >> over -EINTR to allow signals, right? > > Yes, it is needed even for handling linux signals (getting gdb working > for instance). However, since we do not want rt_cond_wait to result into > two syscalls all the time, we handle everything in the first syscall if > possible. > > Try this: > > diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c > index 40e5cfd..d4e885c 100644 > --- a/ksrc/skins/native/syscall.c > +++ b/ksrc/skins/native/syscall.c > @@ -1869,9 +1869,12 @@ static int __rt_cond_wait_prologue(struct pt_regs *regs) > > err = rt_cond_wait_prologue(cond, mutex, &lockcnt, timeout_mode, timeout); > > - if (err == 0 || err == -ETIMEDOUT) > - err = rt_cond_wait_epilogue(mutex, lockcnt); > - > + if (err == 0 || err == -ETIMEDOUT) { > + int loc_err = rt_cond_wait_epilogue(mutex, lockcnt); > + if (loc_err < 0) > + err = loc_err; > + } > + > if (err == -EINTR && __xn_reg_arg3(regs) > && __xn_safe_copy_to_user((void __user *)__xn_reg_arg3(regs), > &lockcnt, sizeof(lockcnt))) No. That is not ok either. We need to store the first status somewhere for returning it to user-space after looping several times in the epilogue function. -- Gilles.