From: Carlos O'Donell <carlos@redhat.com>
To: libc-alpha <libc-alpha@sourceware.org>
Subject: Monday Patch Queue Review update (2022-04-25)
Date: Mon, 25 Apr 2022 18:02:02 -0400 [thread overview]
Message-ID: <730d2593-249e-5adb-2ce1-c2ee9164084b@redhat.com> (raw)
Most recent meeting status is always here:
https://sourceware.org/glibc/wiki/PatchworkReviewMeetings#Update
Meeting: 2022-04-25 @ 0900h EST5EDT
Video/Audio: https://bluejeans.com/9093064454
IRC: #glibc on OFTC.
Review new patches and restart review at the top.
* NEW/NOBODY is at 324 patches.
* Starting at 53184
* v4 Add arc4random support (Adhemerval) 53184
* https://sourceware.org/pipermail/libc-alpha/2022-April/138132.html
* Discussed arc4random support and Adhemerval's implementation.
* Looking to get consensus from Florian Weimer.
* Florian is the author of the previous attempt at an upstreamed impl.
* Looking to decide as a community what direction we would go in.
* 53169 elf: Replace PI_STATIC_AND_HIDDEN with opposite HIDDEN_VAR_NEEDS_DYNAMIC_RELOC
* Adhemerval to look at this.
* 53144 elf: Move post-relocation code of _dl_start into _dl_start_final
* Adhemerval to look at this.
* glibc lacks some clear distinctions around the loader startup.
* Specific barriers are needed here.
* 53127 Support DT_RELR relative relocation format (HJ)
* Pretty much done.
* Try to remove configure knob on this - Turn on DT_RELR by default.
* 53117 INSTALL: Rephrase -with-default-link documentation
* Carlos to respond.
* 53094 Fix deadlock when pthread_atfork handler calls pthread_atfork or dlclose
* Failed CI: Bad test.
* Arjun: Reviewing Adhemerval's patches for this.
* Arjun: What is the consensus for prepare/after handlers added during the fork
in a handler? Should they just become something to use later?
* Adhemerval: When you fork, you use the list as-is.
* Arjun to post new version.
* Arjun to add manual to document pthread_atfork
* Arjun to investigate what to say to the austingroup.
* "If any handler causes a handler to be registered to deregistered then the behaviour of the handler is implementation defined"
* Stopped at 53091.
* Args adjustment with ./ld.so exe [BZ #23293] (szabolcs)
* https://patchwork.sourceware.org/project/glibc/list/?series=8562
* Looking for review.
* Szabolcs to look at adding a test case.
* Sunil: Backporting code into the release branches.
* https://sourceware.org/pipermail/libc-alpha/2022-April/137718.html
* Commit author remains the backpot author
* Author remains the original commit author.
* Cherry-pick -x notes the original commit.
* [v2,1/6] elf: Refactor dl_new_hash so it can be tested / benchmarked (Noah)
* Asking for Florian to review.
* [v5] elf: Fix DFS sorting algorithm for LD_TRACE_LOADED_OBJECTS with missing libraries (BZ #28868)
* Siddhesh to review patch 51584.
--
Cheers,
Carlos.
reply other threads:[~2022-04-25 22:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=730d2593-249e-5adb-2ce1-c2ee9164084b@redhat.com \
--to=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).