From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B8CCC56.3000709@domain.hid> Date: Tue, 02 Mar 2010 09:29:10 +0100 From: Jan Kiszka 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> <4B8C2B3E.8020505@domain.hid> <4B8C2C35.6030006@domain.hid> <4B8C2FE6.5000406@domain.hid> <4B8C30DA.3000705@domain.hid> <4B8C33FC.3080806@domain.hid> <4B8C358E.9050303@domain.hid> In-Reply-To: <4B8C358E.9050303@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig964219BB891EFF1149B94948" Sender: jan.kiszka@domain.hid 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: Gilles Chanteperdrix Cc: "xenomai@xenomai.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig964219BB891EFF1149B94948 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> Same issue exists in user space. And rt_cond_wait_inner needs fixi= ng. >>>>>> And then there is a spurious sign inversion: >>>>>> >>>>>> diff --git a/src/skins/native/cond.c b/src/skins/native/cond.c >>>>>> index 478321d..f874678 100644 >>>>>> --- a/src/skins/native/cond.c >>>>>> +++ b/src/skins/native/cond.c >>>>>> @@ -96,9 +96,9 @@ int rt_cond_wait_until(RT_COND *cond, RT_MUTEX *= mutex, RTIME timeout) >>>>>> &saved_lockcnt, XN_REALTIME, &timeout); >>>>>> =20 >>>>>> while (err =3D=3D -EINTR) >>>>>> - err =3D -XENOMAI_SKINCALL2(__native_muxid, >>>>>> - __native_cond_wait_epilogue, mutex, >>>>>> - saved_lockcnt); >>>>>> + err =3D XENOMAI_SKINCALL2(__native_muxid, >>>>>> + __native_cond_wait_epilogue, mutex, >>>>>> + saved_lockcnt); >>>>>> #endif /* !CONFIG_XENO_FASTSYNCH */ >>>>> Ok for the sign inversion, but in this case the status is Ok. We ca= ll >>>>> cond_wait_epilogue only if prologue returned -EINTR, and update the= >>>>> status, this is what we want. >>>>> >>>>> There is only one way out which will not break the ABI: do not call= >>>>> cond_wait_epilogue in the kernel-space cond_wait_prologue. >>>>> >>>> Unfortunately, that ABI is broken: If we get -ETIMEDOUT on cond wait= an >>>> -EINTR on mutex lock, we lose the former, don't we? >>>> >>>> If we can't find a workaround, I'm for breaking the ABI for this >>>> particular service - but let's search for an alternative first. >>>> >>> The only way around ABI changes: save the return code of cond_wait >>> /somewhere/ across prologue and epilogue syscalls - but where??? >>> >> In-kernel RT_TASK, that's probably the only place. Once >> __rt_cond_wait_epilogue has acquired the mutex (or failed without >> receiving a -EINTR), it can then pick up the original error that this >> task received from rt_cond_wait_prologue and return it. What do you th= ink? >=20 > I was thinking about the same idea, by using the xnthread errno. > However, it is not reentrant, in the sense that if a signal handler > emits a syscall which overrides this value, we are toast. Right. But that's the price someone unable/unwilling to update their user space libs along with the next kernel update will have to pay. I don't expect there are many, though, and the sketched scenario is fairly uncommon as well. So let's head this way: Install some workaround for the existing __rt_cond_wait_prologue syscall, but also introduce __rt_cond_wait_prologue2 which writes the cond-wait error code back like it already happens for lockcnt. That syscall is used by updated user space libs if they find it, otherwise we fall back to the old pattern. Jan --------------enig964219BB891EFF1149B94948 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuMzFkACgkQitSsb3rl5xTEcwCg5mDyeWobc0Y/1bJ/fgAn6YW1 j0YAn0KRl26y7MXV3ktjJMthJqM8hbPx =Yiwg -----END PGP SIGNATURE----- --------------enig964219BB891EFF1149B94948--