[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Aug 2014 13:25:14 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
On Thu, Aug 07, 2014 at 06:47:04PM +0200, Jens Gustedt wrote:
> 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
Says who? The syscall API does not have UB. All inputs are defined,
and cannot cause UB in the userspace process unless the action
requested from the kernel is to modify userspace state in a way that
would cause 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.
No. Invalid addresses are valid arguments to syscalls. They may
produce EFAULT in some cases, but they do not cause UB in the calling
program.
> 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.
Most futex operations (including wait) access an object for read. Some
rarely-used ones write to an object too. Wake does neither. Wake is
purely an operation on the address/futex-waitqueue-object. This
property is not just a side effect but absolutely necessary in order
for futex to be useful, since you _always_ perform the futex wake
after releasing (and thereby potentially allowing destruction) of the
object.
Rich
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.
