From d13bc52fafc1abb0c8e9e51ad8c13ed77a0f2942 Mon Sep 17 00:00:00 2001 From: "A. Wilcox" Date: Mon, 12 Dec 2022 10:04:56 +0000 Subject: user/gstreamer: Fix for time64 issue The patch fixes #853 (libs_gstnetclientclock). The glib-2.72.4 update is actually what fixed #874, as futex was broken on 32-bit architectures. It was affecting PowerPC harder because the MSB was what the kernel was seeing, but in 2038 the other arches would have started seeing the same failures. Fixes: #853, #874 --- user/gstreamer/APKBUILD | 4 ++- user/gstreamer/time64.patch | 60 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 1 deletion(-) create mode 100644 user/gstreamer/time64.patch (limited to 'user/gstreamer') diff --git a/user/gstreamer/APKBUILD b/user/gstreamer/APKBUILD index 8aa1f8a72..94c5af1c9 100644 --- a/user/gstreamer/APKBUILD +++ b/user/gstreamer/APKBUILD @@ -14,6 +14,7 @@ subpackages="$pkgname-dev $pkgname-doc $pkgname-tools $pkgname-lang" source="https://gstreamer.freedesktop.org/src/gstreamer/gstreamer-$pkgver.tar.xz disable-tests.patch test-deadlock.patch + time64.patch " build() { @@ -56,4 +57,5 @@ tools() { sha512sums="d6f67cce81ba15fba3fcf70850e3c84b25e8da3e53fd56e6f2c87c7ee1701071ea44deb754a0ea371b3cb17877f26aab94d9eccb6729cbb370d6d6d5c324aa1a gstreamer-1.20.1.tar.xz 39e6bfb52ebe85beefa2550eb404f83c5bbb3546cc1733b99e757401d2d182f95d829b90df99d5f43506d7c85d4f44ac797f35653cd42a935f1dc56d0b844c02 disable-tests.patch -d7e574e8715607d3103d46eb05388b781702a9e937d78f8cfab6d8d48d04baa7fbfe547bdeb816bbfddb5a333dd1862e460b057b12ea24704351ef5653f78491 test-deadlock.patch" +d7e574e8715607d3103d46eb05388b781702a9e937d78f8cfab6d8d48d04baa7fbfe547bdeb816bbfddb5a333dd1862e460b057b12ea24704351ef5653f78491 test-deadlock.patch +977a9e689cce68b151a742ef67dbb60a10a55fcfae67f086909e1f0fc4a5998026acd03aeed32068fdb0485dd884c4313f39a63e3bab5baaafa878c439531bc3 time64.patch" diff --git a/user/gstreamer/time64.patch b/user/gstreamer/time64.patch new file mode 100644 index 000000000..89c88c380 --- /dev/null +++ b/user/gstreamer/time64.patch @@ -0,0 +1,60 @@ +From 664fc63a246cba97e202f712aa48105f46a9ff69 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= +Date: Mon, 12 Dec 2022 11:34:51 +0200 +Subject: [PATCH] systemclock: Use `futex_time64` syscall on x32 and other + platforms that always use a 32-bit `struct timespec` for the normal `futex` + syscall + +See also https://gitlab.gnome.org/GNOME/glib/-/issues/2634 +--- + gst/gstsystemclock.c | 26 +++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +diff --git a/gst/gstsystemclock.c b/gst/gstsystemclock.c +index 6d0b6ec47b6..8c396d2c7b4 100644 +--- a/gst/gstsystemclock.c ++++ b/gst/gstsystemclock.c +@@ -130,7 +130,31 @@ gst_futex_cond_broadcast (guint * cond_val) + static gboolean + gst_futex_cond_wait_until (guint * cond_val, GMutex * mutex, gint64 end_time) + { ++ /* On x32 (ILP32 ABI on x86_64) and potentially sparc64, the raw futex() ++ * syscall takes a 32-bit timespan argument *regardless* of whether userspace ++ * is using 32-bit or 64-bit `struct timespec`. This means that we can’t ++ * unconditionally pass a `struct timespec` pointer into the syscall. ++ * ++ * Assume that any such platform is new enough to define the ++ * `__NR_futex_time64` workaround syscall (which accepts 64-bit timespecs, ++ * introduced in kernel 5.1), and use that to pass a 64-bit timespec instead. ++ * ++ * `clock_gettime()` on such systems will either return a 32-bit `struct ++ * timespec`, in which case the values we will get passed in here are ++ * already not y2038-safe, or `struct timespec` is using 64-bit `time_t` and ++ * everything is fine. ++ */ ++#ifdef __NR_futex_time64 ++ struct ++ { ++ gint64 tv_sec; ++ gint64 tv_nsec; ++ } end; ++ const long int futex_syscall_id = __NR_futex_time64; ++#else + struct timespec end; ++ const long int futex_syscall_id = __NR_futex; ++#endif + guint sampled; + int res; + gboolean success; +@@ -146,7 +170,7 @@ gst_futex_cond_wait_until (guint * cond_val, GMutex * mutex, gint64 end_time) + /* we use FUTEX_WAIT_BITSET_PRIVATE rather than FUTEX_WAIT_PRIVATE to be + * able to use absolute time */ + res = +- syscall (__NR_futex, cond_val, (gsize) FUTEX_WAIT_BITSET_PRIVATE, ++ syscall (futex_syscall_id, cond_val, (gsize) FUTEX_WAIT_BITSET_PRIVATE, + (gsize) sampled, &end, NULL, FUTEX_BITSET_MATCH_ANY); + success = (res < 0 && errno == ETIMEDOUT) ? FALSE : TRUE; + g_mutex_lock (mutex); +-- +GitLab + -- cgit v1.2.3-60-g2f50