From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8D154B.6050005@domain.hid> Date: Tue, 02 Mar 2010 14:40:27 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B8D0359.4070504@domain.hid> <4B8D0466.7040403@domain.hid> <4B8D0542.1020904@domain.hid> <4B8D05B3.1020202@domain.hid> <4B8D07D7.4040108@domain.hid> <4B8D091A.7070908@domain.hid> <4B8D0BA5.505@domain.hid> <4B8D0CE7.6020101@domain.hid> <4B8D11A6.9070400@domain.hid> <4B8D12FA.6040807@domain.hid> <4B8D13E9.3010109@domain.hid> In-Reply-To: <4B8D13E9.3010109@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : Native: Fix return code of in-kernel rt_cond_wait[_until] List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Ok for returning -EINTR, it is documented. Kernel-space is not so >>>> different from user-space, rt_task_unblock could wake-up a kernel-space >>>> task blocked in a call to rt_cond_wait. >>>> >>>> However, if the epilogue returns an error, we must return it. >>>> >>> OK for this. Pushed an update, but I also modified it further to avoid >>> returning without the mutex lock unless that one is also failing. Maybe >>> in-kernel POSIX requires the same fix, will check. >> Still not OK. You should reacquire the mutex only if the error is 0, >> -ETIMEDOUT or -EINTR. With any other error, we do not know if we can >> call the epilogue safely. > > We _must_ reacquire the mutex - but, granted, we actually have to take > care of invalid cond objects. Lot's of bugs... > Was only an issue of my POSIX patch, native was not touching cond in the epilogue. Update pushed. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux