From: loreb <loreb@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: [PR PATCH] musl: backport patch to fix #37382
Date: Mon, 03 Jul 2023 14:55:34 +0200 [thread overview]
Message-ID: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-44815@inbox.vuxu.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
There is a new pull request by loreb against master on the void-packages repository
https://github.com/loreb/void-packages missing-musl-patch-breaks-musl
https://github.com/void-linux/void-packages/pull/44815
musl: backport patch to fix #37382
<!-- Uncomment relevant sections and delete options which are not applicable -->
#### Testing the changes
- I tested the changes in this PR: **YES**
<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->
<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
#### Local build testing
- I built this PR locally for my native architecture, (x86_64-musl)
<--
- I built this PR locally for these architectures (if supported. mark crossbuilds):
- aarch64-musl
- armv7l
- armv6l-musl
-->
Patch from https://git.musl-libc.org/cgit/musl/commit/?id=a5aff1972c9e3981566414b09a28e331ccd2be5d
Fixes https://github.com/void-linux/void-packages/issues/37382 and afaik shouldn't break anything (I tried rebooting, upgrading, browsing...)
A patch file from https://github.com/void-linux/void-packages/pull/44815.patch is attached
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-missing-musl-patch-breaks-musl-44815.patch --]
[-- Type: text/x-diff, Size: 3305 bytes --]
From f318f360213243b04530c4a1fd7e1504931226bf Mon Sep 17 00:00:00 2001
From: Lorenzo Beretta <vc.net.loreb@gmail.com>
Date: Mon, 3 Jul 2023 14:49:33 +0200
Subject: [PATCH] musl: backport patch to fix #37382
---
...rlimit-misbehavior-and-hang-in-vfork.patch | 49 +++++++++++++++++++
srcpkgs/musl/template | 2 +-
2 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 srcpkgs/musl/patches/avoid-set-id-setrlimit-misbehavior-and-hang-in-vfork.patch
diff --git a/srcpkgs/musl/patches/avoid-set-id-setrlimit-misbehavior-and-hang-in-vfork.patch b/srcpkgs/musl/patches/avoid-set-id-setrlimit-misbehavior-and-hang-in-vfork.patch
new file mode 100644
index 000000000000..21f236b3a6cd
--- /dev/null
+++ b/srcpkgs/musl/patches/avoid-set-id-setrlimit-misbehavior-and-hang-in-vfork.patch
@@ -0,0 +1,49 @@
+From a5aff1972c9e3981566414b09a28e331ccd2be5d Mon Sep 17 00:00:00 2001
+From: Rich Felker <dalias@aerifal.cx>
+Date: Thu, 17 Sep 2020 15:09:46 -0400
+Subject: [PATCH 237/513] avoid set*id/setrlimit misbehavior and hang in
+ vforked/cloned child
+
+taking the deprecated/dropped vfork spec strictly, doing pretty much
+anything but execve in the child is wrong and undefined. however,
+these are commonly needed operations to setup the child state before
+exec, and historical implementations tolerated them.
+
+for single-threaded parents, these operations already worked as
+expected in the vforked child. however, due to the need for __synccall
+to synchronize id/resource limit changes among all threads, calling
+these functions in the vforked child of a multithreaded parent caused
+a misdirected broadcast signaling of all threads in the parent. these
+signals could kill the parent entirely if the synccall signal handler
+had never been installed in the parent, or could be ignored if it had,
+or could signal/kill one or more utterly wrong processes if the parent
+already terminated (due to vfork semantics, only possible via fatal
+signal) and the parent tids were recycled. in any case, the expected
+number of semaphore posts would never happen, so the child would
+permanently hang (with all signals blocked) waiting for them.
+
+to mitigate this, and also make the normal usage case work as
+intended, treat the condition where the caller's actual tid does not
+match the tid in its thread structure as single-threaded, and bypass
+the entire synccall broadcast operation.
+---
+ src/thread/synccall.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/thread/synccall.c b/src/thread/synccall.c
+index 648a6ad4..d58c851f 100644
+--- a/src/thread/synccall.c
++++ b/src/thread/synccall.c
+@@ -63,7 +63,8 @@ void __synccall(void (*func)(void *), void *ctx)
+ sem_init(&target_sem, 0, 0);
+ sem_init(&caller_sem, 0, 0);
+
+- if (!libc.threads_minus_1) goto single_threaded;
++ if (!libc.threads_minus_1 || __syscall(SYS_gettid) != self->tid)
++ goto single_threaded;
+
+ callback = func;
+ context = ctx;
+--
+2.41.0
+
diff --git a/srcpkgs/musl/template b/srcpkgs/musl/template
index 9de13710d7d3..e0e05c2df099 100644
--- a/srcpkgs/musl/template
+++ b/srcpkgs/musl/template
@@ -2,7 +2,7 @@
pkgname=musl
reverts="1.2.0_1"
version=1.1.24
-revision=16
+revision=17
archs="*-musl"
bootstrap=yes
build_style=gnu-configure
next reply other threads:[~2023-07-03 12:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 12:55 loreb [this message]
2023-07-19 22:06 ` [PR PATCH] [Merged]: " classabbyamp
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=gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-44815@inbox.vuxu.org \
--to=loreb@users.noreply.github.com \
--cc=ml@inbox.vuxu.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 NNTP newsgroup(s).