From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8D1D98.5090209@domain.hid> Date: Tue, 02 Mar 2010 15:15:52 +0100 From: Gilles Chanteperdrix 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> <4B8D14BE.8050503@domain.hid> <4B8D164D.7000906@domain.hid> <4B8D16B9.8090609@domain.hid> <4B8D1A07.4050804@domain.hid> <4B8D1AD8.5070507@domain.hid> <4B8D1BE5.6000707@domain.hid> In-Reply-To: <4B8D1BE5.6000707@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: Jan Kiszka Cc: Xenomai core Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> 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... >>>>>> No. If the error is another error than 0, -ETIMEDOUT, or -EINTR, it >>>>>> means that the error was detected prior to freeing the mutex. So, we do >>>>>> not have to re-acquire the mutex. Quoting POSIX: >>>>>> >>>>>> "Except in the case of [ETIMEDOUT], all these error checks shall act as >>>>>> if they were performed immediately at the beginning of processing for >>>>>> the function and shall cause an error return, in effect, prior to >>>>>> modifying the state of the mutex specified by mutex or the condition >>>>>> variable specified by cond." >>>>>> >>>>>> POSIX does not talk about -EINTR, because it states that in this case, >>>>>> we should return 0 to the application. >>>>> OK, but EIDRM was missing in your list. Will adjust both patches. >>>> No, EIDRM is part of the "other errors than ETIMEDOUT and 0" >>>> >>> I interpret the spec fairly differently here: It states that we have to >>> leave the mutex state behind *as if* the error was already detected on >>> entry - thus we are expected to restore its state. >> No. We must return prior to modifying its state. Not change its state >> then restore it. > > "..., _in effect_, prior to modifying the state..." > >> There is no EIDRM anyway, I return 0, and the user gets EINVAL when >> calling pthread_cond_wait again. > > In that case, he may get EPERM later on when trying to release the mutex > he is supposed to hold after cond_wait returned 0. He is not supposed to hold it. He holds it, because we returned 0, and when we return 0, the mutex is re-acquired. > > Jan > -- Gilles.