This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Machine maintainers, please test your machines.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Chris Metcalf <cmetcalf at ezchip dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Tue, 27 Jan 2015 12:11:27 +0100
- Subject: Re: glibc 2.21 - Machine maintainers, please test your machines.
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb> <54C5094A dot 8060300 at ezchip dot com> <54C51D94 dot 6030007 at ezchip dot com> <1422276280 dot 29655 dot 91 dot camel at triegel dot csb> <54C6A1DD dot 4020004 at ezchip dot com> <1422305739 dot 29655 dot 144 dot camel at triegel dot csb> <87a915b170 dot fsf at igel dot home> <1422355938 dot 29655 dot 146 dot camel at triegel dot csb> <mvmmw54mqun dot fsf at hawking dot suse dot de>
On Tue, 2015-01-27 at 11:59 +0100, Andreas Schwab wrote:
> Torvald Riegel <triegel@redhat.com> writes:
>
> > On Mon, 2015-01-26 at 23:56 +0100, Andreas Schwab wrote:
> >> Torvald Riegel <triegel@redhat.com> writes:
> >>
> >> > I don't think so, because in a badly 4B-aligned (ie, no 8B-aligned) use,
> >> > struct new_sem is at offset 4 of the semaphore. If you copy that to a
> >> > 8B-aligned semaphore just bit-by-bit, then the actual data will still
> >> > start at offset 4, but to_new_sem will assume offset 0.
> >>
> >> It is undefined to use a copy of a sem_t in any of the semaphore calls.
> >
> > I think we all agree on that. Nonetheless, as I mentioned previously,
> > I'm not actually aware of where in POSIX (or C?) this would be
> > explicitly forbidden. So if you know that, I'd be interested in getting
> > a reference.
>
> See sem_init.
>
> Only sem itself may be used for performing synchronization. The
> result of referring to copies of sem in calls to sem_wait(),
> sem_timedwait(), sem_trywait(), sem_post(), and sem_destroy() is
> undefined.
Hmm, that was obvious. Thanks for pointing it out :)
- References:
- glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.