From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
libc-alpha <libc-alpha@sourceware.org>,
carlos <carlos@redhat.com>, Rich Felker <dalias@libc.org>,
linux-api <linux-api@vger.kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ben Maurer <bmaurer@fb.com>, Dave Watson <davejwatson@fb.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul <paulmck@linux.vnet.ibm.com>, Paul Turner <pjt@google.com>,
Joseph Myers <joseph@codesourcery.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>
Subject: Re: [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17)
Date: Tue, 28 Apr 2020 08:33:13 -0400 (EDT) [thread overview]
Message-ID: <1080028389.72414.1588077193438.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <87ftcnrf7d.fsf@mid.deneb.enyo.de>
----- On Apr 28, 2020, at 8:02 AM, Florian Weimer fw@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>>>>>> +/* struct rseq is aligned on 4 * 8 bytes to ensure it is always
>>>>>> + contained within a single cache-line.
>>>>>> +
>>>>>> + A single struct rseq per thread is allowed. */
>>>>>> +struct rseq
>>>>>> + {
>>>>>> + /* Restartable sequences cpu_id_start field. Updated by the
>>>>>> + kernel. Read by user-space with single-copy atomicity
>>>>>> + semantics. This field should only be read by the thread which
>>>>>> + registered this data structure. Aligned on 32-bit. Always
>>>>>
>>>>> What does “Aligned on 32-bit” mean in this context? Do you mean to
>>>>> reference 32-*byte* alignment here?
>>>>
>>>> No. I really mean 32-bit (4-byte). Being aligned on 32-byte guarantees that
>>>> this field is aligned at least on 4-byte. This is required by single-copy
>>>> atomicity semantics.
>>>>
>>>> Should I update this comment to state "Aligned on 4-byte" instead ?
>>>
>>> I think this is implied by all Linux ABIs. And the explicit alignment
>>> specification for struct rseq makes the alignment 32 bytes.
>>
>> Unless a structure ends up being packed, which is of course not the case
>> here.
>>
>> I would prefer to keep the comment about 32-bit alignment requirement on
>> the specific fields, because the motivation for alignment requirement is
>> much more strict for fields (correctness) than the motivation for alignment
>> of the structure (performance).
>
> But the correctness is already enforced by the compiler, so I fail to
> see point of mentioning this in the comment.
>
> Anyway, I don't want to make a big deal of it. Please leave it in if
> you think it is ehlpful.
I would prefer to leave it in, just to make the requirements plain clear in
case those structures are allocated on the heap (for instance).
>
>> x32 should not be an issue as explained above, so I'm very open to
>> add this "uptr" for user-space only.
>
> Okay, then please use anonymous unions and structs as necessary, to
> ensure that the uptr field can be reached on all platforms in the same
> way.
OK, will do!
One issue I'm currently facing when running "make check": because nptl/tst-rseq-nptl.c
uses pthread_cancel(), I run into an Abort with:
libgcc_s.so.1 must be installed for pthread_cancel to work
Didn't expect signal from child: got `Aborted'
So far I've tested the rest of that file with a patch on top which disables the use of
pthread_cancel (), but I'd really like to give it a full coverage before sending this out.
In https://sourceware.org/glibc/wiki/Testing/Builds there is a section about
"Building glibc with intent to install" which describes that libgcc must be copied
manually. My use-case is that I just want to run "make check" in the build directory
and make sure it finds the libgcc it needs to succeed using pthread_cancel ().
How can I achieve this ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2020-04-28 12:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200326155633.18236-1-mathieu.desnoyers@efficios.com>
2020-03-26 15:56 ` [PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17) Mathieu Desnoyers
2020-04-27 9:11 ` Florian Weimer
2020-04-27 16:40 ` Mathieu Desnoyers
2020-04-27 16:54 ` Florian Weimer
2020-04-27 17:26 ` Mathieu Desnoyers
2020-04-27 20:27 ` Mathieu Desnoyers
2020-04-28 12:02 ` Florian Weimer
2020-04-28 12:33 ` Mathieu Desnoyers [this message]
2020-04-28 12:35 ` Florian Weimer
2020-04-28 12:43 ` Mathieu Desnoyers
2020-04-28 12:54 ` Florian Weimer
2020-04-28 14:58 ` Mathieu Desnoyers
2020-04-29 8:16 ` Szabolcs Nagy
2020-04-29 8:18 ` Florian Weimer
2020-04-29 8:52 ` Szabolcs Nagy
2020-04-28 12:56 ` Mathieu Desnoyers
2020-04-29 12:19 ` Florian Weimer
2020-04-27 11:59 ` Florian Weimer
2020-04-27 16:47 ` Mathieu Desnoyers
2020-04-27 16:59 ` Florian Weimer
2020-03-26 15:56 ` [PATCH glibc 6/9] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v7) Mathieu Desnoyers
2020-04-27 9:13 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1080028389.72414.1588077193438.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=bmaurer@fb.com \
--cc=boqun.feng@gmail.com \
--cc=carlos@redhat.com \
--cc=dalias@libc.org \
--cc=davejwatson@fb.com \
--cc=fw@deneb.enyo.de \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).