Date: Thu, 07 Aug 2014 18:47:04 +0200 From: Jens Gustedt <jens.gustedt@...ia.fr> To: musl@...ts.openwall.com Subject: Re: Explaining cond var destroy [Re: C threads, v3.0] Am Donnerstag, den 07.08.2014, 12:13 -0400 schrieb Rich Felker: > On Thu, Aug 07, 2014 at 09:50:51AM +0200, Jens Gustedt wrote: > > Am Mittwoch, den 06.08.2014, 19:15 -0400 schrieb Rich Felker: > > > The free operation in thread A is valid since A knows it is the last > > > user of the mutex and thread B's use/ownership of the mutex formally > > > ends with the atomic unlock. > > > > No, operating on an object that has been freed is UB. This is > > No operation is performed on an object which has been freed. ok, let me rephrase passing an invalid userspace address to the kernel for a futex operation is UB > The futex > wake is performed on the _address_, not the object, requesting that > the kernel use the address as a key into a hash table and wake any > threads which are blocked waiting on the futex object associated with > that address. The address is never dereferenced. This is the whole > point of the current design. Yes this is the whole point. But it will not work if you use a invalid address for that. The kernel is doing address translation (in case of a shared futex operation) and for that alone you are supposed to pass in a valid address, I think. And generally for the design of the futex operations some are even designed to compare the actual value to "val" or "val3". I don't think that the kernel guys would give you any guarantee that the kernel would not touch your object, for any of the operations. > > independent of this object being a mutex or not. This must never > > happen. So the free is making a wrong assumption. > > You should clarify whether you mean internal UB in the implementation, > or UB in the application. My understanding is that you meant in the > implementation, but I claim that's wrong. yes I mean implementation, and I am still convinced of it. > > I think the fundamental flaw with this approach is that it mixes two > > different concepts, the waiters count and a reference count. These are > > two different things. > > No, the waiters count is not used as a reference count. Only the state > of the atomic int is used as a reference; once it's set to zero the > implementation can no longer access the object (since another thread > in the application is free to lock, unlock, destroy, and free it). the application cannot directly, but pending application calls into the library can, as we have seen. Jens -- :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.