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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
