On Thu, 2021-07-29 at 19:29 +0200, Jan Kiszka wrote: > On 29.07.21 18:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > On Thu, 2021-07-29 at 17:45 +0200, Jan Kiszka wrote: > > > On 29.07.21 17:06, Philippe Gerum wrote: > > > > > > > > Florian Bezdeka <[email protected]> writes: > > > > > > > > > According to the POSIX spec the value of the timeout parameter needs > > > > > not to be validated if the mutex/semaphore could be taken immediately. > > > > > > > > > > While the implementation of the semaphore timedwait (sem_timedwait()) > > > > > allowed an invalid timeout pthread_mutex_timedlock() was failing with > > > > > -EFAULT in case the mutex could be taken immediately. > > > > > > > > > > Signed-off-by: Florian Bezdeka <[email protected]> > > > > > --- > > > > > > > > > > This was detected while preparing y2038 stuff. Not sure if that should > > > > > go into 3.2. Comments welcome... > > > > > > > > > > > > > upsides: save a few cycles in the non-contended case by not copying in > > > > the timeout from userland uselessly + might help passing some picky > > > > POSIX compliance tests. > > > > > > > > downside: adds an extra atomic op in the contended case. > > > > > > > > > > How do we compare to libc implementations here? > > > > I changed the validation done on cobalt side, not libcobalt. So what > > exactly do you mean? > > > > Indeed, I was looking for the fast or almost fast paths in userspace. > > But now I'm confused: The uncontended case is generally not supposed to > trigger a syscall. That is always the slow path anyway, e.g. because ned > to migrated first (likely how you were able to trigger the issue?).
The fast-path was always fine, that is right. But please note that depending on the kernel configuration (especially with CONFIG_XENO_OPT_DEBUG_MUTEX_SLEEP enabled) we will always be forced into the slow-path. So we had another imbalance depending on the kernel configuration. > > Jan >
